可验证凭证数据模型 v1.1

可验证凭证数据模型 v1.1

W3C推荐标准

有关该文档的更多细节
本版本:
https://www.w3.org/TR/2022/REC-vc-data-model-20220303/
最新发布版本:
https://www.w3.org/TR/vc-data-model/
最新编辑草稿:
https://w3c.github.io/vc-data-model/
历史:
https://www.w3.org/standards/history/vc-data-model
实现报告:
https://w3c.github.io/vc-test-suite/implementations/
编辑:
Manu Sporny (Digital Bazaar) (v1.0, v1.1)
Grant Noble (ConsenSys) (v1.0)
Dave Longley (Digital Bazaar) (v1.0)
Daniel C. Burnett (ConsenSys) (v1.0)
Brent Zundel (Evernym) (v1.0)
Kyle Den Hartog (MATTR) (v1.1)
作者:
Manu Sporny (Digital Bazaar)
Dave Longley (Digital Bazaar)
David Chadwick (University of Kent)
反馈:
GitHub w3c/vc-data-model (pull requests, new issue, open issues)
勘误表:
Errata exists.

参见 翻译.


摘要

凭证是我们日常生活的一部分:驾驶证用来证明我们有能力驾驶机动车,大学学位证被用来证明我们的受教育程度,政府签发的护照让我们能够在不同国家之间旅行。本规范提供了一种机制,可以在Web上以加密安全、隐私保护和机器可验证的方式表达这些凭证

本文档状态

状态更新(2025年6月):此版本已过时!最新版本请参阅https://www.w3.org/TR/vc-data-model/.

本节描述了本文档发布时的状态。当前W3C发布的文档列表和本技术报告的最新版本可在W3C技术报告索引(https://www.w3.org/TR/) 中找到。

欢迎随时对本规范提出意见,但读者应注意,针对此特定版本文档的意见征询期已结束,工作组在此阶段不会对此版本规范进行实质性修改。请直接在GitHub上提交问题,或发送至public-vc-comments@w3.org订阅存档)。

工作组已收到实施反馈,表明规范中的每个规范性功能至少有两个实现。该工作组已获得十四(14)个实施的报告。有关详细信息,请参阅测试套件实施报告

本文档由可验证凭证工作组作为推荐标准在推荐轨道上发布。

W3C建议将本规范广泛部署为Web标准。

W3C推荐标准是指经过广泛协商一致后,由W3C及其成员认可的规范,并且工作组成员承诺对实现进行免版税许可

本文档由遵循W3CW3C专利政策的工作组制定。W3C维护着一份与该工作组交付成果相关的任何专利披露的公开列表;该页面还包含披露专利的说明。知悉某项专利包含基本权利要求的个人必须根据W3C专利政策第6节披露该信息。

本文档受2021年11月2日W3C流程文档的约束。

1. 引言

本章节不包含规范性内容。

凭证是我们日常生活的一部分;驾驶执照用于证明我们有能力驾驶机动车,大学学位可以用于证明我们的教育水平,政府签发的护照使我们能够在国家之间旅行。这些凭证在现实世界中使用时会给我们带来好处,但它们在网络上的使用仍然充满挑战。

目前,在网络上表达教育资格、医疗数据、金融账户信息以及其他类型的经第三方验证的机器可读个人信息仍然较为困难。由于难以在网络上表达数字凭证,导致我们难以通过网络获得与在现实世界中使用实体凭证相同的好处。

本标准提供了一种在网络上以加密安全、尊重隐私且机器可验证的方式表达凭证的标准方法。

对于不熟悉可验证凭证相关概念的读者,以下章节提供了概述:

1.1 什么是可验证凭证?

本章节不包含规范性内容。

在现实世界中,凭证可能包含以下信息:

可验证凭证可以表示与实体凭证相同的所有信息。数字签名等技术的加入使得可验证凭证比其对应的实体凭证更具防篡改性和可信度。

可验证凭证持有者可以生成可验证展示,然后与验证者共享这些可验证展示,以证明他们拥有具有某些特征的可验证凭证

可验证凭证可验证展示都可以快速传输,这使得它们在试图建立远程信任时比其对应的实体凭证更加便捷。

虽然本规范试图提高表达数字凭证的便捷性,但它也试图将这一目标与一系列隐私保护目标相平衡。数字信息的持久性以及轻松收集和关联不同来源的数字数据的便捷性构成了一个隐私问题,使用可验证且易于机器读取的凭证可能会加剧这一问题。本文档在7.隐私注意事项中概述并试图解决其中的一些问题。本文档还提供了关于如何使用增强隐私技术的示例,例如零知识证明。

可验证凭证可验证展示中的“可验证”一词指的是凭证展示能够被验证者验证的特性,如本文档中所定义。凭证的可验证性并不意味着其中编码的声明的真实性可以被评估;但是,签发者可以在evidence属性中包含值,以帮助验证者应用其业务逻辑来确定声明是否具有满足其需求的真实性。

1.2 生态系统概述

本章节不包含规范性内容。

本节描述了在可验证凭证预计有用的生态系统中核心参与者的角色及其之间的关系。角色是一种可以通过多种不同方式实现的抽象概念。角色的分离表明了可能需要标准化的接口和协议。本规范介绍了以下角色:

持有者
一个实体可能通过拥有一个或多个可验证凭证并从中生成可验证展示来扮演的角色。持有者的例子包括学生、员工和客户。
签发者
一个实体通过对一个或多个主体进行声明、从这些声明创建可验证凭证并将可验证凭证传输给持有者所扮演的角色。签发者的例子包括公司、非营利组织、行业协会、政府和个人。
主体
声明对象。主体的例子包括人类、动物和事物。在许多情况下,可验证凭证持有者就是主体,但在某些情况下并非如此。例如,父母(持有者)可能持有孩子的可验证凭证主体),或者宠物主人(持有者)可能持有其宠物的可验证凭证主体)。有关这些特殊情况的更多信息,请参阅附录C.主体-持有者关系
验证者
一个实体通过接收一个或多个可验证凭证(可选地在可验证展示中)进行处理来扮演的角色。验证者的例子包括雇主、安保人员和网站。
可验证数据注册表
一个系统可能执行的一个角色是,创建和验证协调标识符、密钥和其他相关数据(例如可验证凭证模式、撤销注册表、发行者公钥等),这些数据可能是使用可验证凭证所必需的。某些配置可能需要主体的可关联标识符。可验证数据注册表的例子包括可信数据库、去中心化数据库、政府身份证数据库和分布式账本。通常,在一个生态系统中会使用不止一种类型的可验证数据注册表。
diagram showing how
               credentials flow from issuer to holder and
               presentations flow from holder to verifier where all
               three parties can use information from a logical
               verifiable data registry
1 本规范所基于的角色和信息流

图1提供了一个示例生态系统,用以阐释本规范中的其他概念。还存在其他生态系统,例如受保护的环境或专有系统,在这些环境中,可验证凭证也能发挥作用。

1.3 用例和需求

本章节不包含规范性内容。

可验证凭证用例文档[VC-USE-CASES]概述了一些读者可能会觉得有用的关键主题,包括:

在记录和分析用例文档后,针对本规范确定了以下生态系统的理想特征:

1.4 一致性

除了标记为非规范性的部分外,本规范中的所有创作指南、图表、示例和注释均为非规范性的。本规范中的所有其他内容均为规范性的。

本文档中的关键词可以必须禁止建议应该在且仅当它们以全部大写字母出现(本文斜体表示)时,才应按照BCP 14[RFC2119] [RFC8174]中的描述进行解释,如此处所示。

符合规范的文档是符合本规范中规范性声明的数据模型的任何具体表达。具体来说,本文档第4.基本概念5.高级概念6.语法中的所有相关规范性声明必须 强制执行。符合规范的文档的序列化格式 必须 如第6.语法中所述,是确定性的、双向的和无损的。符合规范的文档可以 以任何此类序列化格式传输或存储。

符合规范的处理器是以软件和/或硬件实现的任何算法,用于生成或使用符合规范的文档。当使用不符合规范的文档时,符合规范的处理器必须 产生错误。

本规范不对生态系统中角色(例如签发者持有者验证者)的一致性做出规范性声明,因为生态系统角色的一致性高度依赖于应用程序、用例和垂直市场。

需要数字证明机制(其中一部分是数字签名)来确保可验证凭证的保护。拥有和验证证明(这可能取决于证明的语法,例如,使用JSON Web Token的JSON Web签名来证明密钥持有者)是处理可验证凭证的重要组成部分。在发布时,工作组成员已使用至少三种证明机制实现了可验证凭证

建议实施者注意,并非所有证明机制在本规范发布之日都已标准化。该工作组预计其中一些机制以及新的机制将独立成熟并及时实现标准化。鉴于存在多种有效的证明机制,本规范并未对任何单一数字签名机制进行标准化。本规范的目标之一是提供一个可以被各种当前和未来数字证明机制保护的数据模型。符合本规范并不取决于特定证明机制的细节;它需要清楚地识别可验证凭证使用的机制。

本文档还包含 JSON 和 JSON-LD 内容的示例。其中一些示例包含无效的 JSON 字符,例如内联注释 (//) 和使用省略号 (...)来表示对示例价值不大的信息。如果实施者希望将信息用作有效的 JSON 或 JSON-LD,则应注意删除此内容。

2. 术语

本章节不包含规范性内容。

以下术语用于描述本规范中的概念。

声明(claim)
主体做出的声明。
凭证(credential)
签发者发出的一组或多组声明可验证凭证是一种防篡改凭证,其作者身份可以通过密码学方法进行验证。可验证凭证可用于构建可验证展示,这些展示也可以通过密码学方法进行验证。凭证中的声明可以针对不同的主体
数据最小化(data minimization)
严格限制共享数据量,使其仅达到成功完成任务或目标所需的最低限度的行为。
去中心化标识符(decentralized identifier)
一种基于 URL 的可移植标识符,也称为 DID,与实体相关联。这些标识符最常用于可验证凭证中,并与主体相关联,以便可验证凭证本身可以轻松地从一个存储库移植到另一个存储库,而无需重新签发凭证。DID 的示例是 did:example:123456abcdef
去中心化标识符文档 (decentralized identifier document)
也称为 DID 文档,这是一个可通过可验证数据注册表访问的文档,其中包含与特定去中心化标识符相关的信息,例如关联的存储库和公钥信息。
派生谓词(derived predicate)
关于可验证凭证中另一个属性值的,可验证的布尔声明。这些在零知识证明风格的可验证展示中很有用,因为它们可以限制信息披露。例如,如果可验证凭证包含一个用于表示特定身高(以厘米为单位)的属性,则派生谓词可能会引用可验证凭证中的身高属性,以证明签发者证明身高值满足最低身高要求,而无需实际披露具体身高值。例如,主体高于150厘米。
实体(entity)
具有独特且独立存在的事物,例如在生态系统中扮演一个或多个角色的人员、组织或设备。
图(graph)
主体及其与其他主体或数据的关系组成的信息网络。
持有者(holder)
实体可能扮演的角色,通过拥有一个或多个可验证凭证并从中生成展示持有者通常是(但不总是)其所持有可验证凭证主体持有者将其凭证存储在凭证存储库中。
身份提供者(identity provider)
身份提供者(有时缩写为IdP)是一个用于创建、维护和管理持有者身份信息的系统,同时向联盟或分布式网络中的依赖方应用程序提供身份验证服务。在这种情况下,持有者始终是主体。即使可验证凭证是不记名凭证,也假定可验证凭证仍由主体持有,如果不是,则它们是被攻击者窃取的。除非将本文档中的概念与其他规范进行比较或映射,否则本规范不会使用此术语。本规范将身份提供者概念解耦为两个不同的概念:签发者持有者
签发者(issuer)
实体可以扮演的角色,通过对一个或多个主体做出声明,根据这些声明创建可验证凭证,并将可验证凭证传输给持有者
展示(presentation)
由一个或多个签发者签发的一个或多个可验证凭证派生的数据,这些数据与特定的验证者共享。可验证展示是一种防篡改的展示,其编码方式使得在密码验证过程之后可以信任数据的作者身份。某些类型的可验证展示可能包含从原始可验证凭证合成的数据,但不包含原始可验证凭证(例如,零知识证明)。
存储库(repository)
存储和保护对持有者可验证凭证访问的程序,例如存储库或个人可验证凭证钱包。
选择性披露(selective disclosure)
持有者对共享哪些信息做出细粒度决策的能力。
主体(subject)
声明所针对的事物。
验证(validation)
确保可验证凭证可验证展示满足验证者和其他相关利益相关者的需求。本规范仅限于验证可验证凭证可验证展示,而不考虑其用途。验证可验证凭证可验证展示超出了本规范的范围。
可验证数据注册表(verifiable data registry)
系统可能扮演的角色,通过协调标识符、密钥和其他相关数据的创建和验证(例如,可验证凭证模式、撤销注册表、签发者公钥等),这些数据可能是使用可验证凭证所需的。某些配置可能需要主体的可关联标识符。某些注册表(例如UUID和公钥的注册表)可能只是充当标识符的命名空间。
核验(verification)
评估可验证凭证可验证展示是否是签发者或展示者分别做出的真实、及时的声明。这包括检查:凭证(或展示)是否符合规范;证明方法是否满足;以及(如果存在)状态检查是否成功。凭证的核验并不意味着评估凭证中编码的声明的真实性。
验证者(verifier)
实体通过接收一个或多个可验证凭证(可选地包含在可验证展示中)以进行处理而扮演的角色。其他规范可能会将此概念称为依赖方
URI
统一资源标识符,如[RFC3986]中所定义。

3. 核心数据模型

本章节不包含规范性内容。

以下章节概述了核心数据模型的概念,例如声明凭证展示,这些概念构成了本规范的基础。

3.1 声明

本章节不包含规范性内容。

声明是对主体做出的声明。主体是可以对其进行声明的事物。声明使用主体-属性-关系来表达。

subject has a property which has a value
2 声明的基本结构

声明的数据模型(如上面2所示)功能强大,可以用来表达各种各样的声明。例如,某人是否从某所大学毕业可以用下3所示的方式来表达。

Pat has an alumniOf
            property whose value is Example University
3 声明"Pat是Example大学的校友"的基本结构

多个单独的声明可以合并在一起,以表达关于某个主体的信息。下4所示的示例通过添加“Pat 认识 Sam”和“Sam 受聘为教授”这两个声明扩展了之前的声明

extends previous
            diagram with another property called knows whose value is
            Sam, and Sam has a property jobTitle whose value is Professor
4 可以组合多个声明来表示信息图

至此,我们介绍了声明和信息的概念。为了能够信任声明,我们需要向图中添加更多信息。

3.2 凭证

本章节不包含规范性内容。

凭证是由同一实体发出的一组或多组声明凭证还可以包含标识符和元数据,用于描述凭证的属性,例如签发者、到期日期和时间、代表性图像、用于验证的公钥、撤销机制等等。元数据可由签发者签名。可验证凭证是一组防篡改的声明和元数据,可以通过密码学方法证明其签发者

a Verifible
               Credential contains Credential Metadata, Claim(s), and
               Proof(s)
5 可验证凭证的基本组成部分

可验证凭证的例子包括数字员工证、数字出生证明和数字教育证书。

凭证标识符通常用于标识凭证的特定实例。这些标识符也可以用于关联。如果持有者希望尽量减少关联性,建议使用不透露凭证标识符的选择性披露方案。

上面的5展示了可验证凭证的基本组成部分,但抽象化了声明如何组织成信息,以及信息如何组织成可验证凭证的细节。下面的6展示了可验证凭证的更完整描述,它通常由至少两个信息组成。第一个信息表示可验证凭证本身,其中包含凭证元数据声明。第二个信息表示数字证明,通常是数字签名。

diagram with a
               Credential Graph on top connected via a proof to a
               Proof Graph on the bottom.  The Credental Graph has
               Credential 123 with 4 properties: 'type' of value
               AlumniCredential, 'issuer' of Example University,
               'issuanceDate' of 2010-01-01T19:23:24Z, and
               credentialSubject of Pat, who has an alumniOf property
               with value of Example University.  The Proof Graph has
               Signature 456 with 5 properties: 'type' of
               RsaSignature2018, 'verificationMethod' of Example University
               Public Key 7, 'created' of 2017-06-18T21:19:10Z, and 'jws'
               of 'BavEll0...3JT24='
6 与基本可验证凭证相关的信息图

有些凭证(例如结婚证)可能包含关于不同主体的多个声明,这些主体之间不需要是相关的。

有些凭证可能不包含关于凭证签发对象的任何声明。例如,一个凭证可能只包含关于某只特定狗的声明,但却签发给它的主人。

3.3 展示

本章节不包含规范性内容。

增强隐私性是本规范的一个关键设计特性。因此,对于使用此技术的实体而言,能够仅表达与其特定情境相符的部分身份信息至关重要。这种对自身身份信息子集的表达被称为可验证展示。不同身份信息的示例包括个人的职业身份、网络游戏身份、家庭身份或匿名身份。

可验证展示表达了一个或多个可验证凭证中的数据,并以一种可以验证数据作者身份的方式进行打包。如果直接展示可验证凭证,则它们本身就成为可验证展示。从可验证凭证派生出的数据格式,即使自身不包含可验证凭证,但如果可进行密码学验证,也可能构成可验证展示

展示中的数据通常是关于同一主体的,但可能由多个签发者签发。这些信息的聚合通常表达了一个人、组织或实体的某个方面。

A Verifiable
            Presentation contains Presentation Metadata, Verifiable
            Credential(s), and Proof(s)
7 可验证展示的基本组成部分

上面的7展示了可验证展示的组成部分,但抽象化了可验证凭证如何组织成信息,以及信息图如何组织成可验证展示的细节。

下面的8更完整地描绘了可验证展示,它通常由至少四个信息组成。第一个信息,即展示,表达了可验证展示本身,其中包含展示元数据。展示图中的verifiableCredential属性引用了一个或多个可验证凭证,每个凭证都是信息(第二个信息),即一个自包含的凭证,其中包含凭证元数据和声明。第三个信息,即凭证证明,表达了凭证图的证明,通常是数字签名。第四个信息,即展示证明,表达了展示图的证明,通常也是数字签名。

diagram with
               a Presentation Graph on top connected via a proof to a
               Presentation Proof Graph on the bottom.  The
               Presentation Graph has Presentation ABC with 3
               properties: 'type' of value VerifiablePresentation,
               'termsOfUse' of value Do Not Archive, and
               'verifiableCredential' whose value is Figure 6.  The
               Presentation Proof Graph has Signature 8910 with 5
               properties: 'type' of RsaSignature2018, 'verificationMethod'
               of Example Presenter Public Key 11, 'created' of
               2018-01-15T12:43:56Z, 'challenge' of d28348djsj3239, and
               'jws' of 'p2KaZ...8Fj3K='
8 与基本可验证展示相关联的信息图

可以编写一个展示文档,例如商业角色,可以利用关于不同主体的多个凭证,这些主体通常是相关的,但不要求必须相关。

3.4 具体生命周期示例

本章节不包含规范性内容。

前面的章节使用图形介绍了声明可验证凭证可验证展示的概念。本节提供了一组具体的、简单但完整的生命周期示例,这些示例以本规范支持的其中一种具体语法表达了数据模型。可验证凭证生态系统凭证展示的生命周期通常遵循一个共同的路径:

  1. 一个或多个可验证凭证
  2. 可验证凭证存储在凭证存储库(例如数字钱包)中。
  3. 可验证凭证组合成可验证展示以供验证者使用。
  4. 验证者验证可验证展示

为了说明此生命周期,我们将使用一个从大学兑换校友折扣的示例。在下面的示例中,Pat从大学收到了一个校友可验证凭证,并将该可验证凭证存储在数字钱包中。

随后,Pat 尝试兑换校友折扣。验证者,即票务销售系统,声明“示例大学”的任何校友都可以获得体育赛事季票的折扣。Pat 使用移动设备开始购买季票。此流程中的一个步骤请求提供校友可验证凭证,该请求被路由到Pat的数字钱包。数字钱包询问 Pat 是否愿意提供先前签发的可验证凭证。Pat 选择了校友可验证凭证,然后将其组合成可验证展示可验证展示被发送给验证者并进行验证

有意深入了解上述证明机制的实施者,可以参考第 4.7证明(签名)节以及以下规范:数据完整性 [DATA-INTEGRITY]、链接数据加密套件注册表 [LDP-REGISTRY] 和 JSON Web 签名 (JWS) 未编码载荷选项[RFC7797]。可验证凭证扩展注册表 [VC-EXTENSION-REGISTRY] 中提供了证明机制列表。

4. 基本概念

本章节不包含规范性内容。

本节介绍规范的一些基本概念,为文档后面的5.高级概念做准备。

4.1 上下文

当两个软件系统需要交换数据时,它们需要使用双方都能理解的术语。 举个例子,想想两个人是如何交流的。双方必须使用相同的语言,并且他们使用的词语对彼此来说必须具有相同的含义。这可以被称为对话的上下文。

可验证凭证可验证展示具有许多由URI[RFC3986]标识的属性和值。但是,这些URI可能很长,而且对用户不太友好。在这种情况下,简短易懂的别名会更有帮助。本规范使用@context属性将此类简短别名映射到特定可验证凭证可验证展示所需的URI

在JSON-LD中,@context属性还可以用于传递其他详细信息,例如数据类型信息、语言信息、转换规则等,这些信息超出了本规范的需求,但在将来或相关工作中可能会有用。有关详细信息,请参阅[JSON-LD]规范的第3.1 节“上下文”。

可验证凭证可验证展示必须包含@context属性

@context
@context属性的值必须是一个有序集合,其中第一项是一个值为https://www.w3.org/2018/credentials/v1MURI。作为参考,附录B.1基础上下文提供了基础上下文的副本。数组中的后续项必须表达上下文信息,并且可以由URI或对象的任意组合构成。建议@context中的每个URI在被解引用时,都能解析为一个包含关于@context的机器可读信息的文档。

尽管本规范要求存在 @context 属性,但并不要求使用 JSON-LD 去处理 @context 属性的值。这是为了支持使用普通 JSON 库进行处理,例如在可验证凭证被编码为 JWT 时可能使用的库。所有库或处理器必须确保 @context 属性中值的顺序符合特定应用程序的预期。支持 JSON-LD 的库或处理器可以使用完整的 JSON-LD 处理来处理 @context 属性,如预期的那样。

上述示例使用了基础上下文URI (//www.w3.org/2018/credentials/v1) 来确定对话是关于可验证凭证的。第二个 URI (https://www.w3.org/2018/credentials/examples/v1) 用于表明对话是关于示例的。

本文档使用示例上下文URI (//www.w3.org/2018/credentials/examples/v1) 来演示示例。实施者不应将此URI用于任何其他目的,例如在试点或生产系统中。

https://www.w3.org/2018/credentials/v1上提供的数据是一个静态文档,它永远不会更新,应该下载并缓存。可验证凭证数据模型的相关人类可读词汇表文档可在https://www.w3.org/2018/credentials/上找到。这个概念将在5.3可扩展性中进一步展开。

4.2 标识符

当我们需要描述特定事物(例如个人、产品或组织)的相关信息时,使用某种标识符以便他人也能针对同一事物进行描述,是非常有用的。本规范定义了用于此类标识符的可选id属性id属性旨在明确地指代一个对象,例如一个人、一个产品或一个组织。使用id属性可以在可验证凭证中陈述特定事物。

如果存在id属性

开发者应牢记,在需要匿名性的场景中,标识符可能会带来风险。开发者在考虑此类场景时,建议仔细阅读7.3基于标识符的相关性。此外,7.隐私考量中还记录了其他类型的关联机制,这些机制也会引发隐私问题。在高度重视隐私的情况下,可以省略id属性

id
id属性的值必须是一个URI。建议id中的URI在被解引用时,能够返回一个包含该id的机器可读信息的文档。

上述示例使用了两种类型的标识符。第一种标识符用于可验证凭证,采用基于HTTP的URL。第二种标识符用于可验证凭证的主体(即声明所描述的对象),采用去中心化标识符,也称为DID。

截至本文发布之时,DID是一种新型标识符,并非可验证凭证发挥效用所必需的。具体而言,可验证凭证不依赖于DID,DID也不依赖于可验证凭证。然而,预计许多可验证凭证将会使用DID,并且实现本规范的软件库很可能需要解析DID。基于DID的URL用于表达与主体、签发者、持有者、凭证状态列表、加密密钥以及与可验证凭证相关的其他机器可读信息相关的标识符。

4.3 类型

处理本文档中指定类型的对象的软件系统使用类型信息来确定所提供的可验证凭证可验证展示是否合适。本规范定义了一个用于表达类型信息的type属性

可验证凭证可验证展示必须包含type属性。也就是说,任何不包含type属性的凭证或展示都不可验证,因此这些凭证不是可验证凭证,这些展示也不是可验证展示

type
type属性的值必须是一个或多个URI,或(通过解释@context属性)映射到一个或多个URI。如果提供了多个URI,则必须将这些URI解释为无序集合。应该使用语法便利来简化开发人员的使用。此类便利可能包括JSON-LD术语。建议type中的每个URI在被解引用时,都应返回一个包含关于该类型的机器可读信息的文档。

关于本规范,下表列出了必须指定类型的对象。

对象 类型
可验证凭证对象(凭证对象的子类) verifiableCredential,以及可选的更具体的可验证凭证类型。例如: "type": ["VerifiableCredential", "UniversityDegreeCredential"]
凭证对象 verifiableCredential,以及可选的更具体的可验证凭证类型。例如: "type": ["VerifiableCredential", "UniversityDegreeCredential"]
可验证展示对象(展示对象的子类) VerifiablePresentation,以及可选的更具体的可验证展示类型。例如: "type":["VerifiableCredential", "CredentialManagerPresentation"]
展示对象 VerifiablePresentation,以及可选的更具体的可验证展示类型。例如: "type": ["VerifiableCredential", "CredentialManagerPresentation"]
证明对象 一个有效的证明类型。例如: "type": "RsaSignature2018"
凭证状态对象 一个有效的凭证状态类型。例如: "type": "CredentialStatusList2017"
使用条款对象 一个有效的使用条款类型。例如: "type": "OdrlPolicy2017"
证据对象 一个有效的证据类型。例如: "type": "DocumentVerification2018"

可验证凭证数据模型的类型系统与[JSON-LD]相同,详见其5.4:指定类型。当使用JSON-LD上下文时(参见5.3可扩展性),本规范将@type关键字别名为type,以便JSON-LD文档更易于理解。虽然应用程序开发者和文档作者无需了解JSON-LD类型系统的细节,但希望支持互操作性扩展的本规范实现者则需要了解。

所有凭证、展示文稿和封装对象必须指定或关联其他更具体的类型(例如 UniversityDegreeCredential),以便软件系统可以处理这些附加信息。

在处理本规范中定义的封装对象时(例如,与 credentialSubject 对象关联或深度嵌套在其中的对象),软件系统应该使用封装对象在层次结构中更高层次对象中指定的类型信息。具体来说,封装对象(例如凭证)应该传达关联对象的类型,以便验证者可以根据封装对象的类型快速确定关联对象的内容。

例如,类型为UniversityDegreeCredential的凭证对象向验证者表明,与credentialSubject属性关联的对象包含以下标识符:

这使得实现者可以依赖与type属性关联的值进行验证。对类型及其关联属性的预期应至少记录在人类可读的规范中,最好还记录在其他机器可读的表示形式中。

本规范中描述的数据模型中使用的类型系统允许多种方式将类型与数据关联。强烈建议实现者和作者阅读可验证凭证实施指南[VC-IMP-GUIDE]中关于类型的章节。

4.4 凭证主体

可验证凭证包含关于一个或多个主体的声明。本规范定义了一个credentialSubject属性,用于表达关于一个或多个主体的声明

可验证凭证必须包含credentialSubject属性

credentialSubject
credentialSubject属性的值被定义为一组对象,其中每个对象包含一个或多个与可验证凭证主体相关的属性。每个对象可以包含一个id,如4.2节“标识符”中所述。

可以在可验证凭证中表达与多个主体相关的信息。下面的示例指定了两个作为配偶的主体。请注意,这里使用了数组表示法将多个主体与credentialSubject属性关联。

4.5 签发者

本规范定义了一个用于表达可验证凭证的签发者的属性

可验证凭证必须包含issuer属性

issuer
issuer属性的值必须是一个URI或包含id属性的对象。建议issuer中的URI或其id在被解引用时,能够返回一个包含关于签发者的机器可读信息的文档,该文档可用于验证凭证中表达的信息。

还可以通过将一个对象与issuer属性关联来表达关于签发者的其他信息:

issuer属性的值也可以是JWK(例如,“https://example.com/keys/foo.jwk”)或DID(例如,“did:example:abfe13f712120431c276e12ecab”)。

4.6 签发日期

本规范定义了issuanceDate属性,用于表达凭证生效的日期和时间。

issuanceDate
凭证必须包含issuanceDate属性。issuanceDate属性的值必须是[XMLSCHEMA11-2]中定义的组合日期时间字符串,表示凭证生效的日期和时间,该日期和时间可以是未来的时间点。请注意,此值表示与credentialSubject属性关联的信息开始生效的最早时间点。

预计下一版规范将添加validFrom属性,并弃用issuanceDate属性,转而使用新的issued属性。这两个属性的值范围预计仍将是[XMLSCHEMA11-2]中定义的组合日期时间字符串。建议开发者注意validFrom和issued属性已被保留,不建议将其用于任何其他用途。

4.7证明(签名)

为了使凭证或展示成为可验证凭证可验证展示,即能够被验证,必须表达至少一种证明机制以及评估该证明所需的详细信息。

本规范确定了两类证明机制:外部证明和嵌入式证明。外部证明是对这种数据模型的表达式的包装,例如JSON Web Token,这将在6.3.1节 “JSON Web Token” 中详细阐述。嵌入式证明是一种将证明包含在数据中的机制,例如链接数据签名,这将在6.3.2节“数据完整性证明”中详细阐述。

当嵌入证明时,必须使用proof属性

proof
一个或多个可用于检测篡改和验证凭证或展示作者身份的密码证明。嵌入式证明所使用的具体方法必须使用type属性包含在内。

由于数学证明所使用的方法因表示语言和所用技术而异,因此proof属性的值预计包含的名称-值对集也将相应变化。例如,如果使用数字签名作为证明机制,则proof属性应包含名称-值对,其中包括签名、对签名实体的引用以及签名日期的表示形式。下面的示例使用RSA数字签名。

如1.4节“一致性”中所述,存在多种可行的证明机制,本规范并未标准化或推荐任何单一证明机制用于可验证凭证。有关证明机制的更多信息,请参阅以下规范:数据完整性[DATA-INTEGRITY]、链接数据密码套件注册表[LDP-REGISTRY]和JSON Web签名(JWS)未编码有效负载选项[RFC7797]。可验证凭证扩展注册表[VC-EXTENSION-REGISTRY]中提供了一份证明机制列表。

4.8 过期

本规范定义了expirationDate属性,用于表示凭证过期信息。

expirationDate
如果存在,expirationDate属性的值必须是[XMLSCHEMA11-2]日期时间的字符串值,表示凭证失效的日期和时间。

预计下一版规范将添加validUntil属性,该属性将弃用expirationDate属性,但会保留与之的向后兼容性。建议实施者注意,validUntil属性已被保留,不建议将其用于任何其他目的。

4.9 状态

本规范定义了以下credentialStatus属性,用于发现有关可验证凭证当前状态的信息,例如是否已暂停或撤销。

credentialStatus
如果存在,credentialStatus属性的值必须包含以下内容:
  • id属性,必须是URI
  • type属性,表示凭证状态类型(也称为凭证状态方法)。预计该值将提供足够的信息以确定凭证的当前状态,并且需要能够从URI检索机器可读信息。例如,该对象可以包含指向外部文档的链接,说明该凭证是否已暂停或撤销。

凭证状态信息的精确内容由特定的credentialStatus类型定义确定,并且会因为各种因素的不同(例如其实现是否简单或是否增强隐私性)而有所差异。

定义状态方案的数据模型、格式和协议超出了本规范的范围。可验证凭证扩展注册表[VC-EXTENSION-REGISTRY]中包含了可用状态方案,可供希望实现可验证凭证状态检查的实施者使用。

4.10 展示

展示可以用于组合和呈现凭证。它们可以被打包成一种数据作者身份可验证的方式。展示中的数据通常都与同一个主体相关,但数据中的主体或签发者数量没有限制。聚合来自多个可验证凭证的信息是可验证展示的典型用例。

一个可验证展示通常由以下属性组成:

id
id属性是可选的,可以用于为展示提供唯一的标识符。有关此属性使用的详细信息,请参阅4.2节“标识符”。
type
type属性是必需的,表示展示的类型,例如VerifiablePresentation。有关此属性使用的详细信息,请参阅4.3节“类型”。
verifiableCredential
如果存在,verifiableCredential属性的值必须由一个或多个可验证凭证构成,或以加密可验证格式从可验证凭证派生的数据构成。
holder
如果存在,holder属性的值应为生成展示的实体的URI
proof
如果存在,proof属性的值确保展示是可验证的。有关此属性使用的详细信息,请参阅4.7节“证明(签名)”。

下面的示例展示了一个嵌入了可验证凭证可验证展示

上述的verifiableCredential属性的内容是可验证凭证,如本规范所述。proof属性的内容是证明,如数据完整性[DATA-INTEGRITY]规范所述。第6.3.1节“JSON Web Token”给出了一个使用JWT证明机制的可验证展示示例。

4.10.1 使用派生凭证的展示

一些零知识密码方案可能允许持有者间接证明他们持有来自可验证凭证声明,而无需透露可验证凭证本身。在这些方案中,来自可验证凭证声明可能被用来派生一个展示的值,该值经过密码学声明,使验证者在信任签发者的情况下可以信任该值。

例如,一个包含声明出生日期的可验证凭证可以用来派生“年龄超过15岁”的展示值,该值是可以通过密码学方式验证的。也就是说,如果验证者信任签发者,他们仍然可以信任派生值。

有关包含派生数据而非直接嵌入的可验证凭证的零知识证明风格的可验证展示示例,请参见5.8节“零知识证明”。

使用零知识证明的选择性披露方案可以利用此模型中表达的声明来证明关于这些声明的附加陈述。例如,一个指定主体出生日期的声明可以被用作谓词,以证明主体的年龄在给定范围内,从而证明主体有资格享受与年龄相关的折扣,而无需实际透露主体的出生日期。持有者可以灵活地以任何适用于所需可验证展示的方式使用该声明

Pat has a property
                 dateOfBirth whose value is 2010-01-01
9 一个基本声明,表示Pat的出生日期为2010年1月1日。日期编码将由模式决定。

5. 高级概念

本章节不包含规范性内容。

4. 基本概念的基础上,本章将探讨有关可验证凭证的更复杂主题。

5.1 生命周期细节

本章节不包含规范性内容。

1.2 生态系统概述提供了可验证凭证生态系统的概述。本节将更详细地介绍该生态系统的预期运作方式。

diagram showing how
         credentials flow from issuer to holder, and optionally
         from one holder to another; and how
         presentations flow from holder to verifier, where
         all parties can use information from a logical
         verifiable data registry
10 本规范中的角色和信息流

可验证凭证生态系统中的角色和信息流如下:

上述操作的顺序并非固定不变,某些操作可能会执行多次。此类操作的重复执行可以立即进行,也可以在稍后的任何时间点进行。

最常见操作顺序被设想如下:

  1. 签发者向持有者颁发凭证。
  2. 持有者向验证者出示凭证。
  3. 验证者验证凭证。

本规范未定义任何用于传输可验证凭证或可验证展示的协议,但如果其他规范确实指定了它们如何在实体之间传输,那么本可验证凭证数据模型将直接适用。

本规范也未定义授权框架,也未定义验证者在验证可验证凭证或可验证展示后可能做出的决策,包括考虑持有者、可验证凭证的签发者、可验证凭证的内容及其自身策略。

特别是,第 5.6 节“使用条款”和附录 C“主体-持有者关系”规定了验证者如何确定:

5.2 信任模型

可验证凭证的信任模型如下:

这种信任模型区别于其他信任模型的特点在于确保:

通过将身份提供者和依赖方之间的信任解耦,创建了一种更加灵活和动态的信任模型,从而增强了市场竞争和客户选择。

有关此信任模型如何与工作组研究的各种威胁模型交互的更多信息,请参阅可验证凭证用例文档[VC-USE-CASES]。

本规范中详述的数据模型并不是一种传递式信任模型,例如更传统的证书签发机构信任模型所提供的模型。在可验证凭证数据模型中,验证者要么直接信任签发者,要么不信任签发者。虽然可以使用可验证凭证数据模型构建传递性信任模型,但强烈建议实施者了解以证书签发机构系统采用的方式来广泛委托信任的行为所带来的安全隐患。

5.3 可扩展性

可验证凭证数据模型的目标之一是实现无需许可的创新。为实现此目标,数据模型需要在许多不同方面具有可扩展性。数据模型必须能够:

这种数据建模方法通常被称为开放世界假设,这意味着任何实体都可以对任何其他实体发表任何言论。虽然这种方法似乎与构建简单且可预测的软件系统相冲突,但在开放世界假设下,平衡可扩展性和程序正确性始终比在封闭软件系统中更具挑战性。

本节的其余部分将通过一系列示例来说明如何实现可扩展性和程序正确性。

让我们假设我们从下面显示的可验证凭证开始。

此可验证凭证声明与did:example:abcdef1234567关联的实体的姓名值为Jane Doe

现在让我们假设开发人员想要扩展该可验证凭证,以存储两个额外的信息:一个内部公司参考编号和Jane最喜欢的食物。

首先要做的是创建一个包含两个新术语的 JSON-LD 上下文,如下所示。

创建此JSON-LD上下文后,开发人员将其发布到某个可访问的位置,以便处理可验证凭证的验证者可以访问它。假设上述JSON-LD上下文发布在https://example.com/contexts/mycontext.jsonld,我们可以通过包含上下文并将新的属性和凭证类型添加到可验证凭证中来扩展此示例。

此示例展示了如何以无需许可且去中心化的方式扩展可验证凭证数据模型。所示的机制还确保以这种方式创建的可验证凭证提供了一种防止命名空间冲突和语义歧义的机制。

像这样的动态扩展模型确实增加了实现负担。为这种系统编写的软件必须根据应用程序的风险状况来确定是否可以接受带有扩展的可验证凭证。某些应用程序可能只接受某些扩展,而高度安全的环境可能根本不接受任何扩展。这些决定取决于这些应用程序的开发人员,具体来说并不属于本规范的范围。

强烈建议开发人员确保扩展JSON-LD上下文具有高可用性。无法获取上下文的实现将产生错误。确保扩展JSON-LD上下文始终可用的策略包括对上下文使用内容寻址 URL,将上下文文档与实现捆绑在一起,或启用上下文的积极缓存。

建议实施者密切关注本规范中的扩展点,例如第4.7节“证明(签名)”、第4.9节“状态”、第 5.4 节“数据模式”、第5.5节“刷新”、第5.6节“使用条款”和第5.7节“证据”。虽然本规范没有为这些扩展点定义具体的实现,但可验证凭证扩展注册表[VC-EXTENSION-REGISTRY]提供了一个非官方的、精心策划的扩展列表,开发人员可以从这些扩展点使用这些扩展。

5.3.1 语义互操作性

本规范确保“普通”JSON和JSON-LD语法在语义上兼容,而无需JSON实现使用JSON-LD处理器。为此,规范对两种语法都施加了以下附加要求:

  • 基于JSON的处理器必须处理@context键,确保预期值按处理凭证类型的预期顺序存在。顺序很重要,因为凭证中使用的键(使用与@context关联的值定义)是使用“先定义者优先”机制定义的,更改顺序可能会导致不同的键定义“获胜”。
  • 当JSON-LD上下文重新定义活动上下文中的任何术语时,基于JSON-LD的处理器必须产生错误。更改现有术语定义的唯一方法是引入一个新术语,该术语清除该新术语范围内的活动上下文。对此功能感兴趣的作者应该阅读JSON-LD 1.1规范中的@protected功能。

寻求互操作性的任何实现者都应发布一个人类可读的文档,描述@context属性值的预期顺序。寻求互操作性的JSON-LD实施者应在@context属性指定的URL上发布机器可读的描述(即普通的JSON-LD上下文文档)。

以上要求保证了JSON和JSON-LD之间由@context机制定义的术语的语义互操作性。虽然JSON-LD处理器将使用提供的特定机制并可以验证所有术语是否正确指定,但基于JSON的处理器会隐式接受同一组术语,而无需测试它们是否正确。换句话说,通过使用相同的机制,数据交换发生的上下文在JSON和JSON-LD中都得到了明确说明。对于基于JSON的处理器,这是以轻量级的方式实现的,无需使用JSON-LD处理库。

5.4 数据模式

数据模式在对给定数据集强制执行特定结构时非常有用。本规范至少考虑以下两种类型的数据模式:

重要的是要理解数据模式与@context属性的用途不同,@context属性既不强制执行数据结构或数据语法,也不允许定义到替代表示格式的任意编码。

本规范定义了以下用于表达数据模式的属性,签发者可以在其签发的可验证凭证中包含该属性:

credentialSchema
credentialSchema属性的值必须是一个或多个数据模式,这些模式为验证者提供足够的信息来确定所提供的数据是否符合所提供的模式。每个credentialSchema必须指定其类型(例如,JsonSchemaValidator2018),以及一个id属性,该属性必须是标识模式文件的URI。每个数据模式的精确内容由特定的类型定义确定。

credentialSchema属性提供了一个机会来注释类型定义或将其锁定到词汇表的特定版本。可验证凭证的作者可以使用credentialSchema包含其词汇表的静态版本,该版本锁定到某些内容完整性保护机制。credentialSchema属性还使得可以对凭证执行语法检查,并使用诸如JSON Schema[JSON-SCHEMA-2018]验证之类的验证机制。

在上面的示例中,签发者指定了一个credentialSchema,它指向一个[JSON-SCHEMA-2018]文件,验证者可以使用该文件来确定可验证凭证是否格式规范。

有关JSON Schema[JSON-SCHEMA-2018]或其他可选验证机制的链接信息,请参阅可验证凭证实施指南[VC-IMP-GUIDE]文档。

数据模式还可以用于指定到其他二进制格式的映射,例如用于执行零知识证明的格式。有关将credentialSchema属性与零知识证明一起使用的更多信息,请参阅5.8节“零知识证明”。

在上面的示例中,签发者指定了一个credentialSchema,它指向一种零知识打包二进制数据格式,该格式能够将输入数据转换为一种格式,然后验证者可以使用该格式来确定可验证凭证提供的证明是否有效。

5.5 刷新

本章节不包含规范性内容。

系统能够手动或自动刷新过期的可验证凭证非常有用。有关过期可验证凭证的更多信息,请参阅4.8过期部分。本规范定义了一个refreshService属性,使签发者可以包含指向刷新服务的链接。

如果签发者希望验证者或持有者(或两者)使用刷新服务,则可以将其作为元素包含在可验证凭证中;如果仅供持有者使用,则可以将其包含在可验证展示中。在后一种情况下,持有者可以在创建要与验证者共享的可验证展示之前刷新可验证凭证。在前一种情况下,将刷新服务包含在可验证凭证中,使持有者或验证者都可以执行凭证的未来更新。

刷新服务预计仅在凭证过期或签发者未发布凭证状态信息时使用。建议签发者不要将refreshService属性放在不包含公共信息或其刷新服务未以某种方式受到保护的可验证凭证中。

将refreshService属性放在可验证凭证中以便验证者可以使用它,可能会剥夺持有者的控制权和同意权,并允许将可验证凭证直接颁发给验证者,从而绕过持有者。

refreshService
refreshService属性的值必须是一个或多个刷新服务,它们向接收者的软件提供足够的信息,以便接收者可以刷新可验证凭证。每个refreshService值都必须指定其类型(例如,ManualRefreshService2018)及其ID,即服务的URI。预期需要能够从URI检索机器可读信息。每个刷新服务的精确内容由特定的refreshService类型定义确定。

在上面的示例中,签发者指定了一个手动刷新服务,可以通过引导持有者或验证者访问https://example.edu/refresh/3732来使用它。

5.6 使用条款

本章节不包含规范性内容。

使用条款可以被签发者或持有者用于传达可验证凭证或可验证展示发布的条款。签发者将其使用条款置于可验证凭证内。持有者将其使用条款置于可验证展示内。本规范定义了一个termsOfUse属性来表达使用条款信息。

termsOfUse属性的值告诉验证者如果要接受可验证凭证或可验证展示,它需要执行哪些操作(义务)、不允许执行哪些操作(禁止)或允许执行哪些操作(许可)。

需要进一步研究以确定非持有者的主体如何在他们的可验证凭证上放置使用条款。一种方法可能是主体请求签发者将使用条款置于已颁发的可验证凭证内。另一种方法可能是主体将可验证凭证委托给持有者,并在委托的可验证凭证上放置使用条款限制。

termsOfUse
termsOfUse属性的值必须指定创建者签发凭证或展示所依据的一个或多个使用条款政策。如果接收者(持有者或验证者)不愿意遵守指定的使用条款,则他们自行承担责任,并且如果他们违反了规定的使用条款,可能会承担法律责任。每个termsOfUse值都必须指定其类型,例如IssuerPolicy,并且可以指定其实例ID。每个使用条款的具体内容由特定的termsOfUse类型定义确定。

在上面的示例中,签发者(转让人)禁止验证者(受让人)将数据存储在档案库中。

警告:termsOfUse属性在可验证展示范围的上下文中定义不正确。这是版本1上下文中的一个错误,将在版本2上下文中修复。与此同时,希望使用此功能的实施者将需要使用定义termsOfUse属性的附加术语扩展其可验证展示的上下文,然后可以将其与可验证展示类型属性一起使用,以便JSON-LD处理器能够在语义上识别该术语。

在上面的示例中,持有者(转让人),同时也是主体,表达了一项使用条款,禁止验证者(受让人,https://wineonline.example.org)使用提供的信息通过第三方服务关联持有者或主体。如果验证者使用第三方服务进行关联,则他们将违反持有者创建展示的条款。

预计此功能也将被政府签发的可验证凭证使用,以指示数字钱包将其使用限制在类似的政府组织,试图保护公民免受敏感数据被意外使用。类似地,预计私营行业签发的一些可验证凭证会将其使用限制在组织内部的部门内,或在工作时间内。敦促实施者在可验证凭证实施指南[VC-IMP-GUIDE]文档的相应部分中阅读更多关于此快速发展功能的信息。

5.7 证据

本章节不包含规范性内容。

签发者可以在可验证凭证中包含证据,以便为验证者提供额外的支持信息。验证者可以使用这些信息来确定其对可验证凭证中声明的信任程度。

例如,签发者可以在签发凭证之前检查主体提供的物理文件或执行一系列背景调查。在某些情况下,当确定依赖于给定凭证的相关风险时,此信息对验证者很有用。

本规范定义了用于表达证据信息的evidence属性。

evidence
evidence属性的值必须是一个或多个证据方案,提供足够的信息,以便验证者确定签发者收集的证据是否满足其依赖凭证的置信度要求。每个证据方案都通过其类型进行标识。id属性是可选的,但如果存在,则应包含一个指向该证据实例的更多信息的URL。每种证据方案的具体内容由特定的证据类型定义所决定。

有关规范如何支持附件以及对凭证和非凭证数据的引用的信息,请参阅可验证凭证实施指南[VC-IMP-GUIDE]文档。

在此证据示例中,签发者声明他们将凭证的主体与所述驾照号码的驾照的物理副本进行了物理匹配。此驾照在签发过程中除了被用于验证“示例大学”在颁发凭证之前验证了主体,还用于展现他们是如何进行验证的(物理验证)。

evidence属性提供与proof属性不同且互补的信息。evidence属性用于表达支持信息,例如与可验证凭证的完整性相关的文件证据。与evidence属性相反,proof属性用于表达与签发者的真实性和可验证凭证的完整性相关的机器可验证的数学证明。有关proof属性的更多信息,请参见第4.7节 证明(签名)。

5.8 零知识证明

本章节不包含规范性内容。

零知识证明是一种密码学方法,实体可以借此向另一实体证明其知道某个值,而无需披露该值的实际内容。现实世界中的一个例子是证明一所经认可的大学授予了你学位,而无需透露你的身份或学位证书上包含的任何其他个人身份信息。

零知识证明机制引入的关键功能使持有者能够:

本规范描述了一个支持使用零知识证明机制进行选择性披露的数据模型。以下示例重点介绍了如何使用该数据模型来签发、展示和验证零知识可验证凭证。

为了使持有者能够使用零知识可验证展示,他们需要签发者以一种能够使持有者从最初签发的可验证凭证中派生证明的方式签发可验证凭证,以便持有者能够以增强隐私的方式向验证者展示信息。这意味着持有者可以在不透露已签名值的情况下,或仅在透露某些选定值时,证明签发者签名的有效性。标准做法是通过证明对签名的知识来实现,而无需透露签名本身。当可验证凭证要在零知识证明系统中使用时,它们有两个要求。

以下示例展示了在零知识中使用可验证凭证的一种方法。它使用了Camenisch-Lysyanskaya签名[CL-SIGNATURES],该签名允许以支持持有者和主体隐私的方式展示可验证凭证,方法是选择性地披露可验证凭证的值。其他一些依赖零知识证明来选择性披露属性的密码系统也可以在[LDP-REGISTRY]中找到。

上述示例通过使用credentialSchema属性和Camenisch-Lysyanskaya零知识证明系统中可用的特定证明,提供了可验证凭证的定义。

下一个示例利用上述可验证凭证生成一个带有隐私保护证明的新派生可验证凭证。然后将派生可验证凭证放入可验证展示中,以便于让该可验证凭证仅披露持有者预期的声明和其他凭证元数据。为此,预期满足以下所有要求:

Verifiable
            Credential 1 and Verifiable Credential 2 on the left map
            to Derived Credential 1 and Derived Credential 2 inside a
            Presentation on the right.  Verifiable Credential 1
            contains Context, Type, ID, Issuer, Issue Date, Expiration
            Date, CredentialSubject, and Proof, where
            CredentialSubject contains GivenName, FamilyName, and
            Birthdate and Proof contains Signature, Proof of
            Correctness, and Attributes.  Verifiable Credential 2
            contains Context, Type, ID, Issuer, Issue Date, Expiration
            Date, CredentialSubject, and Proof, where
            CredentialSubject contains University, which contains
            Department, which contains DegreeAwarded, and Proof contains Signature, Proof of
            Correctness, and Attributes.  The Presentation diagram on
            the right contains Context, Type, ID,
            VerifiableCredential, and Proof, where
            VerifiableCredential contains Derived Credential 1 and
            Derived Credential 2 and Proof contains Common Link
            Secret.  Derived Credential 1 contains Context, Type, ID,
            Issuer, Issue Date, CredentialSubject, and Proof, where
            CredentialSubject contains AgeOver18 and Proof contains
            Knowledge of Signature.  Derived Credential 2 contains
            Context, Type, ID, Issuer, Issue Date, CredentialSubject,
            and Proof, where CredentialSubject contains Degree and
            Proof contains Knowledge of Signature.  A line links
            Birthdate in Verifiable Credential 1 to AgeOver18 in
            Derived Credential 1.  A line links DegreeAwarded in
            Verifiable Credential 2 to Degree in Derived Credential 2.
11 零知识证明展示中凭证与派生凭证关系的直观示例。presentation.

本文档特意省略了有关凭证定义和证明格式的重要细节,因为它们超出了本文档的范围。本节旨在指导希望扩展可验证凭证和可验证展示以支持零知识证明系统的实施者。

5.9 争议处理

本章节不包含规范性内容。

体希望对签发者签发的凭证提出异议,至少需要考虑以下两种情况:

  1. 主体对签发者提出的声明存在异议。 例如,地址属性不正确或已过期。
  2. 实体对签发者针对其他主体提出的可能存在虚假的声明存在异议。 例如,冒名顶替者声称拥有某个实体的社会安全号码。

发出争议凭证的机制与常规凭证相同,区别在于争议凭证属性中的credentialSubject标识符是被争议凭证的标识符。

例如,如果对标识符为https://example.org/credentials/245的凭证存在争议,主体可以发出如下所示的凭证,并将其与有争议的凭证一起提交给验证者。

在上述可验证凭证中,签发者声称有争议的可验证凭证中的地址是错误的。

如果凭证没有标识符,可以使用内容寻址标识符来识别有争议的凭证。同样,内容寻址标识符也可以用来唯一地标识个体声明。

该研究领域正在快速发展,有意愿发布质疑其他凭证真实性的凭证的开发者,强烈建议阅读可验证凭证实施指南[VC-IMP-GUIDE]文档中与争议相关的部分。

5.10 授权

本章节不包含规范性内容。

可验证凭证旨在作为一种可靠识别主体身份的方式。尽管基于角色访问控制(RBAC)和基于属性访问控制(ABAC)都依赖于这种身份识别作为授权主体访问资源的手段,但本规范并未提供完整的RBAC或ABAC解决方案。若没有相应的授权框架,本规范不适用于授权用途。

工作组在制定本规范期间确实考虑了授权用例,并正在将其作为构建在本规范之上的架构层进行研究。

6. 语法

3. 核心数据模型4. 基本概念5. 高级概念中描述的数据模型是可验证凭证或可验证可验证展示的规范结构表示。所有序列化都是该数据模型在特定格式下的表现形式。本节将具体说明数据模型如何在 JSON-LD 和简单 JSON 中实现。尽管只为这两种语法提供了语法映射,但应用程序和服务可以使用任何其他能够表达数据模型的数据表示语法(例如 XML、YAML 或 CBOR)。由于验证核验要求是根据数据模型定义的,因此所有序列化语法都必须能够确定性地转换为数据模型,以便进行处理、验证或比较。本规范对任何特定序列化格式的支持均不做要求。

本规范中属性值的预期基数以及存储这些值的结果数据类型可能因属性而异。如果存在,以下属性将表示为单个值:

所有其他属性(如果存在)将表示为单个值或值数组。

6.1 JSON格式

3. 核心数据模型中所描述的数据模型,可以通过以下方式将属性值映射到 JSON 类型,从而以JavaScript对象表示法(JSON)[RFC8259]进行编码:

由于此处列出的转换可能存在互相矛盾的解释,因此需要对JSON格式进行进一步的分析,以便提供结果为数据模型的确定性转换。

6.2 JSON-LD

[JSON-LD]是一种基于JSON的格式,用于序列化关联数据。其语法设计旨在轻松融入已部署的、使用 JSON 的系统,并提供从JSON到[JSON-LD]的平滑升级路径。 JSON-LD 主要用于在基于Web的编程环境中使用关联数据,构建可互操作的Web服务,以及在基于JSON的存储引擎中存储关联数据。

在扩展本规范描述的数据模型时,[JSON-LD]非常有用。数据模型的实例与在 JSON(6.1 JSON格式)中编码相同的方式在[JSON-LD]中编码, 并添加了@context属性JSON-LD上下文在[JSON-LD]规范中有详细描述,其用法在5.3 可扩展性中进行了阐述。

可以使用或组合多个上下文,以便使用惯用的 JSON 来表达关于可验证凭证的任意信息。JSON-LD上下文位于https://www.w3.org/2018/credentials/v1,是一个静态文档,永远不会更新,因此可以下载并缓存在客户端。 可验证凭证数据模型的相关词汇表文档位于https://www.w3.org/2018/credentials

6.2.1 语法糖

总的来说,本文档中描述的数据模型和语法旨在方便实施者能够复制粘贴示例,将可验证凭证集成到他们的软件系统中。这种方法的设计目标是降低入门门槛,同时仍然确保不同软件系统之间的全局互操作性。 本节将介绍其中的一些方法,大多数开发者可能不会注意到这些方法,但其实现细节对于开发者来说却至关重要。[JSON-LD]提供的最值得注意的语法糖包括:

  • @id@type关键字分别被赋予idtype的别名,使开发者能够将本规范作为惯用的 JSON 使用。
  • 数据类型,如整数、日期、计量单位和 URL,会被自动进行类型化,以便为需要它们的用例提供更强的类型保证。
  • verifiableCredentialproof属性被视为图形容器。即它们是用于隔离由不同实体声明的数据集的机制。 例如,这确保了每个签发者提供的数据图和持有者向验证者提供的可验证凭证的数据图之间具有适当的密码学隔离,以确保每个图信息的来源得到保留。
  • [JSON-LD] 1.1 的@protected属性特性被用于确保本规范定义的术语不被覆盖。 这意味着,只要在可验证凭证可验证展示的顶部声明相同的@context,无论数据模型的用户是否使用[JSON-LD]处理器,对于所有被理解的术语,都能保证互操作性。

6.3 证明格式

本规范中描述的数据模型被设计成与证明格式无关的。本规范没有强制要求任何特定的数字证明或签名格式。尽管数据模型是凭证展示的规范表示形式,但这些证明机制通常与各方之间传输文档时使用的语法相关联。 因此,每种证明机制都必须指定证明的验证是针对传输的文档状态、可能转换后的数据模型还是针对其他形式进行计算。在发布时,至少有两种证明格式被实施者积极使用,工作组认为记录这些证明格式是什么以及它们是如何被使用的将有利于实施者。 详细介绍当前被积极用于签发可验证凭证的证明格式的章节如下:

6.3.1 JSON Web Token

JSON Web Token (JWT) [RFC7519] 仍然是一种广泛使用的方式,用于在双方之间传递声明。为JWT提供可验证凭证数据模型的表示,允许现有系统和库参与1.2 生态系统概述中描述的生态系统。 JWT 将一组声明编码为 JSON 对象,该对象包含在JSON Web签名(JWS)[RFC7515]或JWE[RFC7516]中。在本规范中,JWE的使用不在讨论范围之内。

与可验证凭证数据模型的关系

本规范定义了可验证凭证数据模型在JWT和JWS上的编码规则。它进一步定义了如何以及何时使用特定的JWT注册声明名称和特定的JWS注册标头参数名称的处理规则,以允许基于 JWT 的系统符合本规范。 如果存在这些特定的声明名称和标头参数,则可以省略标准可验证凭证可验证展示中相应的部分,以避免重复。

JSON Web Token扩展

本规范引入了两个新的注册声明名称,它们包含标准可验证凭证可验证展示中没有明确 JWT 编码规则的部分。这些对象在 JWT 有效负载中按如下方式封装:

JWT和JWS注意事项
JWT 编码

为了将可验证凭证编码为 JWT,本规范引入的特定属性必须满足以下条件之一:

  • 编码为标准JOSE标头参数,或
  • 编码为注册的JWT声明名称,或
  • 包含在JWS签名部分中。

如果没有明确的规则,则属性将以与标准凭证相同的方式进行编码,并添加到JWT的vc声明中。 与所有JWT一样,在应用任何解码或转换规则之前,以JWT语法表示的可验证凭证的基于JWS的签名是针对网络上传输的文字JWT字符串值计算的。以下段落描述了这些编码规则。

如果存在 JWS,数字签名指的是可验证凭证签发者;在可验证展示的情况下,数字签名指的是可验证凭证持有者。 JWS证明JWT的iss签署了包含的JWT有效负载,因此可以省略proof属性

如果不存在 JWS,则必须提供proof属性proof属性可用于表示更复杂的证明,例如当创建者与签发者不同时,或者证明不基于数字签名(例如工作量证明)时,可能需要这样做。 签发者可以同时包含JWS和proof属性。出于向后兼容性的原因,签发者必须使用JWS来表示基于数字签名的证明。

以下规则适用于本规范上下文中的JOSE标头:

  • 对于数字签名,必须设置alg。如果所选签名方法只需要proof属性(即,如果该方法中没有算法选择),则alg标头必须设置为none
  • 如果有多个密钥与JWT的签发者关联,则可以使用kid。密钥发现不在本规范的范围内。例如,kid可以引用DID文档中的密钥,或者可以是JWKS中密钥的标识符。
  • 如果存在 typ,则必须将其设置为JWT

为了向后兼容JWT处理器,必须使用以下注册的JWT声明名称来代替或补充其各自的标准可验证凭证对应项:

  • exp必须表示expirationDate属性,编码为UNIX时间戳(NumericDate)。
  • iss必须表示可验证凭证的issuer属性或可验证展示的holder属性
  • nbf必须表示issuanceDate,编码为UNIX时间戳(NumericDate)。
  • jti必须表示可验证凭证可验证展示id属性
  • sub必须表示credentialSubject中包含的id属性
  • bearer credentialspresentations中,sub将不存在。

  • aud必须表示(即识别)可验证展示的目标受众(即提交可验证展示持有者希望接收并验证该展示的验证者)。

文中未明确指出的其他JOSE标头参数和JWT声明名称,只要其使用未被明令禁止,均可使用。其他可验证凭证声明必须添加至JWT的credentialSubject属性中。

有关使用本文档未指定的 JOSE 标头参数和/或 JWT 声明名称的更多信息,请参阅《可验证凭证实施指南》[VC-IMP-GUIDE]。

本规范版本未对高级概念章节中概述的概念(例如,refreshServicetermsOfUseevidence)定义任何JWT特定的编码规则。 这些概念无需任何转换即可按原样编码,并且可以添加到vc JWT声明中。

实施者需要注意,JSON Web Token(JWT)目前无法编码多个主体,因此无法对包含多个主体可验证凭证进行编码。 JWT未来可能会支持多个主体,建议开发者参考JSON Web Token声明注册表中关于多主体JWT声明名称的说明,或查阅 嵌套JSON Web Token规范。

JWT解码

要将 JWT 解码为标准的凭证展示必须执行以下转换:

  1. 创建一个JSON对象。
  2. vcvp声明中的内容添加到新的JSON对象中。
  3. 转换剩余的JWT特定头部和声明,并将结果添加到新的凭证展示JSON对象中。

要转换JWT特定的头部和声明必须执行以下操作:

  • 如果存在exp,则必须将UNIX时间戳转换为[XMLSCHEMA11-2]日期时间格式,并将其用于设置新JSON对象的credentialSubjectexpirationDate属性值。
  • 如果存在iss,则必须使用其值设置新凭证JSON对象的issuer属性或新展示JSON对象的holder属性
  • 如果存在nbf,则必须将UNIX时间戳转换为[XMLSCHEMA11-2]日期时间格式,并将其用于设置新 JSON 对象的issuanceDate属性值。
  • 如果存在sub,则必须使用其值设置新凭证JSON对象的credentialSubjectid属性值。
  • 如果存在jti,则必须使用其值设置新JSON对象的id属性值。

在上述示例中,可验证凭证采用了基于JWS数字签名的证明方式,相应的核验密钥可以通过kid头参数获取。

在上面的例子中,vc不包含id属性,因为 JWT 编码使用jti属性来表示唯一标识符。 sub属性编码了credentialSubjectid属性所代表的信息。nonce已被添加以阻止重放攻击。

在上述示例中,可验证展示使用了基于JWS数字签名的证明,相应的验证密钥可以通过kid标头参数获取。

在上面的例子中,vp不包含id属性,因为 JWT 编码使用jti属性来表示唯一标识符。 verifiableCredential包含一个字符串数组,其中包含使用JWT紧凑序列化格式的可验证凭证。添加了nonce(随机数)以防止重放攻击。

6.3.2 数据完整性证明

本规范利用关联数据,通过URL和JSON-LD等标准在Web上发布信息,以标识主体及其相关属性。 当信息以这种方式呈现时,其他相关信息可以很容易地被发现,新的信息也可以很容易地合并到现有的知识图谱中。 关联数据以一种去中心化的方式进行扩展,极大地降低了大规模集成的障碍。 本规范中的数据模型与数据完整性和相关的关联数据加密套件能够很好地协同工作,这些套件旨在保护本规范所描述的数据模型。

与JSON Web Token的使用不同,数据完整性证明无需任何额外的预处理或后处理。 数据完整性证明格式旨在简单、轻松地保护可验证凭证可验证展示。保护可验证凭证可验证展示就像将本规范中的有效示例传递给关联数据签名实现并生成数字签名一样简单。

有关不同语法格式(例如 JSON+JWT、JSON-LD+JWT 或 JSON-LD+LD-Proofs)质量的更多信息,请参阅《可验证凭证实施指南》[VC-IMP-GUIDE] 文档。

7. 隐私考量

本章节不包含规范性内容。

本节详细介绍了将可验证凭证数据模型部署到生产环境中的一般隐私考量和具体隐私影响。

7.1 隐私范围

本章节不包含规范性内容。

务必认识到,隐私范围涵盖从匿名到强身份识别的各个层面。根据用例的不同,人们对于愿意提供的信息以及可以从所提供信息中推断出的信息,其接受程度也各不相同。

Horizontal bar with
            red on the left, orange in the middle, and green on the
            right.  The red has the text 'Highly correlatable (global
            IDs), e.g., government ID, shipping address, credit card
            number'.  The orange has the text 'Correlatable ia collusion
            (personally identifiable info), e.g., name, birthday, zip
            code'.  The green has the text 'Non-correlatable
            (pseudonyms), e.g., age over 21'.
12 隐私范围:从假名到完全识别

例如,大多数人在购买酒类时可能希望保持匿名,因为监管检查仅仅基于一个人是否达到特定年龄。 相反,对于医生为病人开具的医疗处方,药房在配药时需要更严格地识别医务人员和病人。因此,没有一种适用于所有用例的隐私方法。隐私解决方案是特定于用例的。

即使是那些希望在购买酒类时保持匿名的人,可能仍然需要提供照片身份证明,以便让商家获得适当的保证。 商家可能不需要知道你的姓名或其他详细信息(除了你超过特定年龄),但在许多情况下,仅仅证明年龄可能仍然不足以满足法规要求。

可验证凭证数据模型致力于支持全方位的隐私需求,并且不对任何特定交易的匿名程度采取既定的立场。以下部分为希望避免特定隐私敌对场景的实施者提供指导。

7.2 个人身份信息

本章节不包含规范性内容。

存储在可验证凭证credential.credentialSubject字段中的数据,在与验证者共享时容易遭受隐私侵犯。 个人身份数据,例如政府签发的身份证件、收货地址和全名,很容易被用来确定、跟踪和关联一个实体。 即使是看似非个人身份的信息,例如出生日期和邮政编码的组合,也具有非常强大的关联和去匿名化能力。

强烈建议实施者在持有者共享此类特征的数据时发出警告。 强烈建议签发者尽可能提供保护隐私的可验证凭证。例如,当验证者想要确定一个实体是否超过18岁时,签发ageOver可验证凭证而不是出生日期可验证凭证

由于可验证凭证通常包含个人身份信息 (PII),因此强烈建议实施者在存储和传输可验证凭证时使用保护数据不被未授权访问的机制。 可以考虑的机制包括传输层安全 (TLS) 或其他在传输过程中加密数据的方法,以及在静态存储时加密或数据访问控制机制来保护可验证凭证中的数据。

7.3 基于标识符的相关性分析

本章节不包含规范性内容。

可验证凭证主体是通过credential.credentialSubject.id字段进行标识的。用于标识主体的标识符如果长期存在或跨多个网络域名使用,则会增加关联风险。

类似地,公开凭证标识符(credential.id)会导致多个验证者签发者验证者合谋关联持有者的情况。如果持有者希望减少关联,他们应该使用允许在可验证展示期间隐藏标识符的可验证凭证方案。 此类方案期望持有者生成标识符,甚至可能允许对签发者隐藏标识符,同时仍然将标识符嵌入并签名到可验证凭证中。

如果在可验证凭证系统中需要强大的反关联特性,强烈建议标识符满足以下条件之一:

7.4 基于签名的关联性分析

本章节不包含规范性内容。

可验证凭证的内容通过credential.proof字段进行安全保护。 当字段中的属性值在多个会话或域中重复使用且保持不变时,会增加关联性分析的风险。 例如verificationMethodcreatedproofPurposejws字段。

如果需要强大的反关联性,建议每次都使用第三方双向签名、零知识证明或群签名等技术重新生成签名值和元数据。

即使使用反关联签名,可验证凭证中也可能包含信息,这些信息会削弱所用密码学的反关联性。

7.5 基于长期标识符的相关性分析

本章节不包含规范性内容。

可验证凭证可能包含长期标识符,这些标识符可用于关联个人身份。 这类标识符包括主体标识符、电子邮件地址、政府签发的标识符、组织签发的标识符、地址、医疗健康信息、可验证凭证特定的 JSON-LD 上下文,以及许多其他类型的长期标识符。

持有者提供软件的组织应努力识别可验证凭证中包含的可能用于关联个人身份信息的字段,并在共享此类信息时向持有者发出警告。

7.6 设备指纹识别

本章节不包含规范性内容。

可验证凭证存在一些外部机制,可以用来追踪和关联互联网和万维网上的个人身份。这些机制包括互联网协议 (IP) 地址追踪、网页浏览器指纹识别、永久性 Cookie、广告网络追踪器、移动网络位置信息以及应用程序内全球定位系统 (GPS) API。 使用可验证凭证并不能阻止这些追踪技术的使用。此外,当这些技术与可验证凭证结合使用时,可能会发现新的可关联信息。例如,生日与 GPS 位置信息结合起来,可以强有力地关联个人在多个网站上的活动。

建议尊重隐私的系统在使用可验证凭证时,应阻止使用这些追踪技术。在某些情况下,可能需要在代表持有者传输可验证凭证的设备上禁用追踪技术。

7.7 倾向于使用抽象声明

本章节不包含规范性内容。

为了使可验证凭证的接收者能够在各种情况下使用它们,而不会泄露超出交易所需范围的个人身份信息 (PII),签发者应考虑将凭证中发布的信息限制为预期用途所需的最小集合。 避免在凭证中包含 PII 的一种方法是使用抽象属性,这种属性可以满足验证者的需求,而无需提供关于主体的具体信息。

例如,本文档使用ageOver属性而不是具体的出生日期,因为后者构成了更强的 PII。 如果特定市场的零售商通常要求购买者达到特定年龄,则在该市场中受信任的签发者可以选择提供声称主体已满足该要求的可验证凭证,而不是提供包含特定出生日期声明可验证凭证。这使得个人客户能够在不泄露特定 PII 的情况下进行购买。

7.8 数据最小化原则

本章节不包含规范性内容。

当在一个情境下披露的信息泄露到另一个情境时,就会发生隐私侵犯。防止此类侵犯的公认最佳实践是将请求和接收的信息限制在绝对必要的最低限度。 这种数据最小化方法已在多个司法管辖区的法规中强制要求,包括美国的《健康保险流通与责任法案》(HIPAA) 和欧盟的《通用数据保护条例》(GDPR)。

对于可验证凭证签发者的数据最小化意味着将可验证凭证的内容限制在潜在验证者预期用途所需的最低限度。对于验证者,数据最小化意味着限制访问服务时请求或要求的信息范围。

例如,包含驾驶员身份证号码、身高、体重、生日和家庭住址的驾驶执照就是一个包含的信息超出确定该人是否超过特定年龄所需信息的凭证

签发者最好将信息原子化或使用允许选择性披露的签名方案。例如,驾驶执照的签发者可以签发包含驾驶执照上所有属性的可验证凭证,以及一组每个可验证凭证仅包含单个属性(例如,一个人的生日)的可验证凭证。 它还可以发布更抽象的可验证凭证(例如,仅包含ageOver属性的可验证凭证)。一种可能的改进是签发者提供安全的 HTTP 端点,用于检索一次性持有者凭证,以促进可验证凭证的匿名使用。 如果实施者认为这不切实际或不安全,则应考虑使用选择性披露方案,以消除在证明时对签发者的依赖,并降低签发者的时序关联风险。

强烈建议验证者仅请求特定交易发生绝对必要的信息。这至少有两个重要原因:

虽然可以践行最小披露原则,但在单个会话或多个会话期间,对于特定用例,可能无法避免对个人进行强身份识别。本文档的作者无法准确说明在现实场景中满足这一原则的难度。

7.9 持有者凭证

本章节不包含规范性内容。

持有者凭证是一种增强隐私的信息载体,例如音乐会门票,它赋予持有者获得特定资源的权利,而无需透露持有者的敏感信息。 持有者凭证通常用于低风险场景,在这些场景中,共享凭证并不会引发担忧,也不会造成重大的经济或声誉损失。

可验证凭证可以通过不指定主体标识符来实现持有者凭证的功能,该标识符通常使用嵌套在credentialSubject属性中的id属性来表示。例如,以下可验证凭证就是一个持有者凭证

虽然持有者凭证可以增强隐私,但其设计必须谨慎,以免意外泄露超出持有者预期之外的信息。 例如,在多个站点重复使用相同的持有者凭证,可能导致这些站点合谋,对持有者进行过度跟踪或关联。 同样,看似非身份识别信息(例如出生日期和邮政编码),如果在同一持有者凭证或会话中同时使用,也可用于统计识别个人身份。

持有者凭证签发者应确保持有者凭证提供的隐私增强优势能够:

如果签发或请求的持有者凭证包含敏感信息,或者在一次或多次会话中组合两个或多个持有者凭证存在关联风险,软件应向持有者发出警告。 虽然不可能检测到所有关联风险,但其中一些风险无疑是可以被察觉的。

验证者不应请求可能用于过度关联持有者持有者凭证

7.10 有效性检查

本章节不包含规范性内容。

在处理可验证凭证时,验证者应执行A. 验证中列出的许多检查,包括验证以及各种特定的业务流程检查。有效性检查可能包括检查:

执行这些检查的过程可能会导致信息泄露,从而侵犯持有者的隐私。 例如,像检查撤销列表这样简单的操作就可以通知签发者某个特定企业可能正在与持有者进行交互。这可能使签发者能够在持有者不知情的情况下合谋并关联个人信息。

强烈建议签发者不要在核验过程中使用可能导致隐私泄露的机制,例如针对每个凭证都唯一的凭证撤销列表。 为持有者提供软件的组织应警告凭证中包含的信息是否可能在验证过程中导致隐私泄露。验证者应考虑拒绝那些会侵犯隐私或导致不良隐私行为的凭证

7.11 存储提供商与数据挖掘

本章节不包含规范性内容。

持有者签发者处收到可验证凭证后,该可验证凭证需要存储在某个地方(例如,凭证存储库)。持有者需要注意的是,可验证凭证中的信息具有敏感性和高度个性化特征,使其成为数据挖掘的高价值目标。 一些宣称提供免费可验证凭证存储的服务,实际上可能是在挖掘个人数据并将其出售给希望构建个人和组织个性化档案的机构。

持有者需要了解其凭证存储库的服务条款,特别是针对将可验证凭证存储在该服务提供商处的用户所提供的关联和数据挖掘保护措施。

一些有效缓解数据挖掘和画像的方法包括:

7.12 凭证聚合

本章节不包含规范性内容。

即使信息来自不同的渠道,掌握同一主体两条信息也几乎总会比这两条信息简单相加所能揭示的更多。可验证凭证的聚合存在隐私风险,生态系统中的所有参与者都需要意识到数据聚合的风险。

例如,如果在多次会话中提供了两个持有者凭证,一个用于电子邮件地址,另一个表明持有者年龄超过 21 岁,那么信息验证者现在就拥有了该个人的唯一标识符以及年龄相关信息。 这样一来,创建和构建持有者档案就变得轻而易举,随着时间的推移,越来越多的信息会被泄露。凭证聚合也可以通过多个站点相互合谋来执行,从而导致侵犯隐私。

从技术的角度来看,防止信息聚合是一个非常难以解决的隐私问题。 虽然新的密码学技术,如零知识证明,被提议作为解决聚合和关联问题的方案,但长期存在的标识符和浏览器跟踪技术的存在,即使是最现代的密码学技术也无法克服。

关联或聚合带来的隐私问题的解决方案往往不是技术性的,而是政策驱动的。因此,如果持有者不希望自己的信息被聚合,他们必须在他们传输的可验证展示中表达这一点。

7.13 使用模式

本章节不包含规范性内容。

尽管已尽最大努力确保隐私,但实际使用可验证凭证仍可能导致去匿名化和隐私泄露。当出现以下情况时,可能会发生这种关联:

在某种程度上,可以通过以下方式减轻这种去匿名化和隐私泄露:

可以理解的是,这些缓解技术并不总是切实可行的,甚至与必要的用途不兼容。有时关联是必需的。

例如,在某些处方药监控程序中,使用监控是一项要求。执法机构需要能够确认个人没有欺骗系统以获取多种受管制物质的处方。这种关联使用的法定或监管需求凌驾于个人隐私问题之上。

可验证凭证也将用于有意地跨服务关联个人,例如,当使用通用角色登录多个服务时,所有这些服务上的所有活动都会有意地链接到同一个人。只要每个服务都以预期的方式使用关联,这就不是隐私问题。

凭证的提交产生意外或非预期的关联时,就会出现凭证使用的隐私风险。

7.14 信息误分享

本章节不包含规范性内容。

持有者选择与验证者分享信息时,验证者有可能出于恶意行为并请求可能对持有者造成损害的信息。例如,验证者可能会索要银行账号,然后将其与其他信息一起用于欺诈持有者或银行。

签发者应努力将尽可能多的信息进行令牌化处理,以便在持有者意外地将凭证传输给错误的验证者时,不至于造成灾难性的后果。

例如,与其为了查询个人银行余额而直接提供银行账号,不如提供一个令牌,使验证者能够查询余额是否高于特定金额。在这种情况下,银行可以向持有者签发包含余额查询令牌的可验证凭证。 然后,持有者可验证凭证包含在可验证展示中,并使用数字签名将令牌绑定到征信机构。验证者随后可以用其数字签名封装可验证展示,并将其交还给签发者以动态查询账户余额。

使用这种方法,即使持有者与错误方共享了账户余额令牌,攻击者也无法获取银行账号,也无法获知账户的确切金额。并且,鉴于会签的有效期,攻击者对令牌的访问权限不会超过几分钟。

7.15 签发凭证的频率

本章节不包含规范性内容。

正如7.13 使用模式中详细描述的那样,使用模式可以关联到某些类型的行为。 当持有者签发者不知情的情况下使用可验证凭证时,这种关联性会被部分削弱。然而,签发者可以通过缩短可验证凭证的有效期并使其自动续期来克服这种保护措施。

例如,一个ageOver可验证凭证可以用来进入酒吧。如果签发者签发的此类可验证凭证有效期非常短,并且具有自动续期机制,那么签发者就有可能关联持有者的行为,从而对持有者产生负面影响。

持有者提供软件的组织应该警告他们,如果他们反复使用有效期很短的凭证,可能会导致行为关联。签发者应避免以能够关联使用模式的方式签发凭证

7.16 优先使用一次性凭证

本章节不包含规范性内容。

一个理想的、尊重隐私的系统应当只要求持有者披露与验证者交互的必要信息。验证者随后会记录披露要求已得到满足,并忘记任何已披露的敏感信息。在许多情况下,诸如监管负担等相互竞争的优先事项会阻碍这种理想系统的实施。 在其他情况下,长期存在的标识符会妨碍单次使用。然而,任何可验证凭证生态系统的设计都应尽可能地尊重隐私,尽可能优先考虑使用一次性可验证凭证

使用一次性可验证凭证具有诸多益处。首先,验证者可以确信可验证凭证中的数据是最新的。其次,持有者知道,如果可验证凭证中没有长期存在的标识符,那么该可验证凭证本身就不能用于在线跟踪或关联他们。 最后,攻击者也无从下手,使整个生态系统更加安全可靠。

7.17 私密浏览

本章节不包含规范性内容。

理想情况下,私密浏览模式不会泄露任何个人身份信息 (PII)。由于许多凭证都包含 PII,因此,为持有者提供软件的组织应提醒他们,如果希望在私密浏览模式下使用凭证展示,则有可能泄露这些信息。 鉴于每个浏览器厂商对私密浏览的处理方式不同,并且某些浏览器可能根本不具备此功能,因此,开发者务必了解这些差异并相应地调整方案。

7.18 签发者合作对隐私的影响

本章节不包含规范性内容。

可验证凭证高度依赖于对签发者的信任,这一点怎么强调都不为过。持有者能够利用各种隐私保护措施的程度,往往很大程度上取决于签发者对这些功能的支持力度。 在许多情况下,诸如零知识证明、数据最小化技术、持有者凭证、抽象声明以及防签名关联等隐私保护措施,都需要签发者积极支持并将它们融入到其签发的可验证凭证之中。

还需注意的是,除了依赖签发者参与提供有助于保护持有者主体隐私的可验证凭证功能外,持有者还依赖于签发者不会故意破坏隐私保护。例如,签发者可以使用一种防止签名关联的签名方案来签发可验证凭证。 这将保护持有者在与验证者共享凭证时,不会因签名值而被关联起来。 然而,如果签发者为每个签发的凭证都创建一个唯一的密钥,那么签发者就有可能跟踪凭证展示情况,即使验证者无法做到这一点。

8. 安全注意事项

本章节不包含规范性内容。

在处理本规范所述数据时,签发者持有者验证者应注意诸多安全问题。忽略或不理解本节内容的含义可能导致安全漏洞。

虽然本节试图强调广泛的安全注意事项,但它并非详尽无遗。强烈建议实施者在使用本规范概述的技术实施关键任务系统时,寻求安全和密码学专家的建议。

8.1 密码套件与库

本章节不包含规范性内容。

(本节为非规范性内容)

本规范中描述的数据模型的某些方面可以通过密码学技术进行保护。开发者务必了解用于创建和处理凭证展示的密码套件和库。密码系统的实施和审计通常需要深厚的专业知识。此外,有效的红队测试也有助于消除安全审查中的主观偏差。

密码套件和库都有其生命周期,新的攻击手段和技术进步最终会使其过时。生产级系统需要考虑到这一点,并确保能够轻松、主动地升级过时或失效的密码套件和库,同时具备使现有凭证失效和替换的机制。定期监控对于保障凭证处理系统的长期有效性至关重要。

8.2 内容完整性保护

本章节不包含规范性内容。

本节为非规范性内容。

可验证凭证通常包含指向凭证本身以外数据的 URL。链接到可验证凭证外部的内容,如图像、JSON-LD 上下文和其他机器可读数据,通常无法防止篡改,因为这些数据位于可验证凭证的保护范围之外。例如,以下高亮显示的链接没有受到内容完整性保护,但或许应该受到保护:

尽管本规范没有推荐任何特定的内容完整性保护措施,但建议希望确保内容链接得到完整性保护的文档作者使用强制执行内容完整性的 URL 方案。[HASHLINK]规范和[IPFS]就是两个这样的方案。下面的示例对前面的示例进行了转换,并使用[HASHLINK]规范为 JSON-LD 上下文添加了内容完整性保护,并使用[IPFS]链接为图像添加了内容完整性保护。

以上 JSON-LD 上下文是否需要保护存在争议,因为生产环境的实现预计会附带重要JSON-LD 上下文的静态副本。

虽然上述示例是一种实现内容完整性保护的方法,但某些应用场景可能需要其他解决方案。实施者务须了解,如果链接到未受内容完整性保护的外部机器可读内容,可能会导致应用程序遭受攻击。

8.3 无签名声明

本章节不包含规范性内容。

本规范允许生成不包含任何签名或证明的凭证。此类凭证通常适用于中间存储或自我声明的信息,类似于填写网页上的表单。实施者应注意,此类凭证无法验证,因为其作者身份未知或不可信。

8.4 令牌绑定

本章节不包含规范性内容。

验证者可能需要确保它是可验证展示的预期接收者,而不是中间人攻击的目标。诸如令牌绑定 [RFC8471] 之类的方法,它将可验证展示的请求与响应绑定在一起,可以保护协议的安全。任何不安全的协议都容易受到中间人攻击。

8.5 绑定依赖声明

本章节不包含规范性内容。

建议签发者凭证中的信息原子化,或使用允许选择性披露的签名方案。在原子化的情况下,如果签发者没有安全地进行原子化,持有者可能会以签发者不期望的方式将不同的凭证绑定在一起。

例如,一所大学可能会向一个人签发两份可验证凭证,每份凭证包含两个属性,这两个属性必须结合在一起才能指定该人在特定“部门”中的“角色”,例如“计算机系”的“工作人员”或“经济学系”的“研究生”。如果将这些可验证凭证原子化,以便每个凭证只包含其中一个属性,则大学将向该人签发四份凭证,每份凭证包含以下名称之一:“工作人员”、“研究生”、“计算机系”和“经济学系”。然后,持有者可能会将“工作人员”和“经济学系”可验证凭证转移给验证者,这两个凭证加在一起将构成虚假声明

8.6 高动态信息

本章节不包含规范性内容。

可验证凭证用于发布高动态信息时,实施者应确保适当地设置过期时间。如果过期时间超过可验证凭证的有效期限,则可能产生可利用的安全漏洞。如果过期时间短于可验证凭证所表达信息的有效期限,则会给持有者验证者带来负担。因此,为可验证凭证设置与其用例和凭证中包含信息的预期生命周期相适应的有效期至关重要。

8.7 设备失窃和身份冒用

本章节不包含规范性内容。

可验证凭证存储在设备上,且该设备丢失或被盗时,攻击者有可能使用受害者的可验证凭证访问系统。缓解此类攻击的方法包括:

9. 可访问性考量

本章节不包含规范性内容。

在处理本规范中描述的数据时,实施者应注意许多可访问性考量。与任何网络标准或协议的实施一样,忽视可访问性问题将导致很大一部分人群无法使用这些信息。遵循可访问性指南和标准(例如 [WCAG21])至关重要,以确保所有能力水平的人都能使用这些数据。这在建立使用密码学的系统时尤为重要,因为这些系统历来对辅助技术造成了困扰。

本节详细介绍了使用此数据模型时需要考虑的总体无障碍因素。

9.1 数据优先方法

本章节不包含规范性内容。

目前使用的许多实体凭证,例如政府身份证,都存在较差的可访问性特征,包括但不限于:字体过小、依赖小型高分辨率图像,以及对视障人士缺乏便利设施。

在利用此数据模型创建可验证凭证时,建议数据模型设计者采用数据优先的方法。例如,在选择使用数据或图形图像来描述凭证时,设计者应该以机器可读的方式表达图像的每个元素,例如机构名称或专业凭证,而不是依赖观看者对图像的解读来传达此信息。数据优先方法更受青睐,因为它为构建针对不同能力人士的不同界面提供了基础要素。

10. 国际化考量

本章节不包含规范性内容。

建议开发者在发布符合本规范的数据时,注意一些国际化方面的考量。与任何网络标准或协议的实现一样,忽略国际化会导致数据难以跨越不同的语言和社会环境进行生成和使用,从而限制规范的适用性,并显著降低其作为标准的价值。

强烈建议开发者阅读 W3C 国际化行动发布的《网络上的字符串:语言和方向元数据》文档[STRING-META],该文档详细阐述了提供可靠的文本元数据以支持国际化的必要性。若需了解国际化考量的最新信息,也建议开发者阅读《可验证凭证实施指南》 [VC-IMP-GUIDE] 文档。

本节概述了在使用此数据模型时需要考虑的一般国际化因素,旨在重点介绍《网络上的字符串:语言和方向元数据》文档 [STRING-META] 中开发者可能感兴趣的特定部分。

10.1 语言和基本方向

本章节不包含规范性内容。

强烈建议数据发布者阅读《网络上的字符串:语言和方向元数据》文档 [STRING-META] 中关于跨语法表达的部分,以确保语言和基本方向信息的表达能够跨越多种表达语法,例如[JSON-LD]、[JSON] 和 CBOR [RFC7049]。

表示带有语言标签和可选的特定基准方向的文本字符串时,通常的设计模式是使用以下标记模板。

使用上述设计模式,以下示例在不指定文本方向的情况下,用英文表达了一本书的标题。

下一个示例采用了类似的标题,以阿拉伯语书写,其基本书写方向是从右到左。

以上文字如果没有明确的语言和方向指示,很有可能会被错误地渲染成从左到右的排列方式,因为很多系统会根据文本字符串的第一个字符来判断文本方向。

强烈建议使用 JSON-LD 的实施者扩展定义国际化属性的 JSON-LD 上下文,并利用 JSON-LD的作用域上下文特性,将 @value、@language 和 @direction 关键字分别简写为 value、lang和 dir。 以下示例代码片段展示了如何实现这一点。

10.2 复杂语言标记

本章节不包含规范性内容。

当单个自然语言字符串中使用多种语言、书写方向和注释时,通常需要更复杂的机制。可以使用 HTML 等标记语言对包含多种语言和书写方向的文本进行编码。也可以使用 rdf:HTML数据类型在 JSON-LD 中准确编码此类值。

尽管可以将信息编码为 HTML,但强烈建议实施者避免这样做,原因如下:

如果实施者认为必须使用 HTML 或其他能够包含可执行脚本的标记语言来解决特定用例,建议他们分析攻击者将如何利用标记对标记使用者发起注入攻击,然后针对已识别的攻击部署缓解措施。

A. 验证

本章节不包含规范性内容。

尽管本规范没有为可验证凭证可验证展示验证过程提供一致性标准,但读者可能仍然好奇验证者验证过程中将如何使用此数据模型中的信息。本节摘录了工作组就验证者对本规范中数据字段的预期使用情况进行的一些讨论。

A.1 凭证主体

本章节不包含规范性内容。

在持有者出示的可验证凭证中,每个 credentialSubject 的 id 属性所关联的值预期用于向验证者标识主体。如果持有者同时也是主体,并且验证者拥有与持有者相关的公钥元数据,那么验证者就可以对持有者进行身份验证。验证者可以使用可验证展示中包含的、由持有者生成的签名来进行身份验证。id 属性是可选的。验证者可以使用可验证凭证中的其他属性来唯一标识主体。

有关身份验证和WebAuthn如何与可验证凭证协同工作的信息,请参阅《可验证凭证实施指南》[VC-IMP-GUIDE]文档。

A.2 签发者

本章节不包含规范性内容。

签发者属性的值预期用于识别一个验证者知晓并信任的签发实体。

签发者属性相关的元数据预期可供验证者使用。例如,签发者可以发布包含其用于对其签发的可验证凭证进行数字签名的公钥的信息。这些元数据在检查可验证凭证的证明时非常重要。

A.3 签发日期

本章节不包含规范性内容。

签发日期预期在验证者的预期范围内。例如,验证者可以检查可验证凭证的颁发日期是否在未来。

A.4 证明(签名)

用于证明可验证凭证可验证展示中的信息未被篡改的加密机制称为证明。存在多种类型的加密证明,包括但不限于数字签名、零知识证明、工作量证明和权益证明。通常,在验证证明时,预期实现能够确保:

一些证明是数字签名。通常,在验证数字签名时,预期实现能够确保:

除了防篡改之外,数字签名还提供了许多其他并非显而易见的保护。例如,创建的链接数据签名属性会建立一个日期和时间,在此之前不应将凭证视为已验证。verificationMethod属性指定了例如可用于验证数字签名的公钥。解引用公钥URL会显示有关密钥控制者的信息,可以将其与凭证签发者进行核对。 proofPurpose属性清楚地表达了证明的目的,并确保此信息受到签名的保护。证明通常附加到可验证展示以进行身份验证,并附加到可验证凭证作为声明的方法。

A.5 有效期

本章节不包含规范性内容。

验证者预期 verifiable credential 的 expirationDate(有效期)字段值应在一个合理的范围内。例如,验证者可以检查可验证凭证的有效期是否已过期。

A.6 状态

本章节不包含规范性内容。

如果存在credentialStatus(凭证状态)属性可用,验证者预期将根据verifiable credential的credentialStatus类型定义以及验证者自身的状态评估标准,对可验证凭证的状态进行评估。例如,验证者可以确保可验证凭证的状态不是“已被签发者撤销”。

A.7 用途适用性

本章节不包含规范性内容。

用途适用性是指verifiable credential中的自定义属性是否适合验证者的用途。例如,如果验证者需要确定主体是否年满21岁,他们可能依赖于特定的birthdate(出生日期)属性,或者更抽象的属性,例如ageOver(超过…岁)。

验证者信任签发者做出的声明。例如,一家特许经营的快餐店相信该特许经营总部的优惠券声明。除非持有者和验证者愿意承担忽略策略的责任,否则他们应遵守签发者在verifiable credential中表达的策略信息。

B. 上下文、类型与凭证模式

本章节不包含规范性内容。

B.1 基础上下文

本章节不包含规范性内容。

基础上下文位于 https://www.w3.org/2018/credentials/v1,其 SHA-256 摘要值为ab4ddd9a531758807a79a5b450510d61ae8d147eab966cc9a200c07095b0cdcc,可以用于实现本地缓存副本。为方便起见,本节还提供了该基础上下文。

B.2 上下文、类型和凭证模式之间的区别

本章节不包含规范性内容。

可验证凭证可验证展示数据模型利用了多种底层技术,包括 [JSON-LD] 和[JSON-SCHEMA-2018]。本节将比较 @context、type 和 credentialSchema 属性,并涵盖一些可以更具体地使用数据模型这些功能的用例。

type 属性用于唯一标识其出现的可验证凭证的类型,即指示可验证凭证包含哪些声明集合。此属性及其值集合中的 VerifiableCredential 值是必需的。虽然建议包含一个描述此可验证凭证唯一子类型的值,但允许在数组中省略或包含其他类型值。许多验证者会请求特定子类型的可验证凭证,因此省略子类型值可能会使验证者更难以告知持有者他们需要哪种可验证凭证。当可验证凭证具有多个子类型时,将所有子类型都列在 type 属性中是合理的。虽然在[JSON] 和 [JSON-LD] 表示形式中语义相同,但在可验证凭证的 [JSON-LD] 表示形式中使用type 属性能够比相同凭证的 [JSON] 表示形式更好地强制执行可验证凭证的语义,因为机器能够检查语义。使用 [JSON-LD],该技术不仅描述了声明集的分类,还传达了图中属性子图的结构和语义。在 [JSON-LD] 中,这表示图中节点的类型,这就是为什么可验证凭证的一些[JSON-LD] 表示形式会在可验证凭证中的许多对象上使用 type 属性的原因。

从 [JSON-LD] 的角度来看,@context 属性的主要目的是以机器可读的方式传达可验证凭证中数据的含义和术语定义。在编码纯 [JSON] 表示形式时,@context 属性仍然是必需的,并为全局语义提供了一些基本支持。@context 属性用于将可验证凭证可验证展示中属性的全局唯一 URI 映射到简短的别名,使 [JSON] 和 [JSON-LD] 表示形式更易于人类阅读。从 [JSON-LD] 的角度来看,这种映射还允许通过增强可验证凭证可验证展示中的数据与更大的机器可读数据图的关系,将凭证中的数据建模在机器可读数据网络中。这对于告诉机器如何在各方无法协调的生态系统中将数据的含义与其他数据相关联非常有用。此属性是必需的,其集合中的第一个值是 https://www.w3.org/2018/credentials/v1。

由于 @context 属性用于将数据映射到图数据模型,并且 [JSON-LD] 中的 type 属性用于描述图中的节点,因此在组合使用这两个属性时,type 属性变得更加重要。例如,如果未使用 [JSON-LD] 在解析的 @context 资源中包含 type 属性,则可能导致在生成和使用可验证凭证期间删除声明和/或不再保护其完整性。或者,它可能导致在生成或使用可验证凭证期间引发错误。这将取决于实现的设计选择,并且当前的实现中使用了这两种路径,因此在使用可验证凭证可验证展示的 [JSON-LD] 表示形式时,务必注意这些属性。

credentialSchema 属性的主要目的是定义可验证凭证的结构以及出现的每个属性值的数据类型。credentialSchema 对于定义可验证凭证中一组声明的内容和结构很有用,而可验证凭证中的 [JSON-LD] 和 @context 最好仅用于传达数据的语义和术语定义,他们也可以用于定义可验证凭证的结构。

虽然可以使用一些 [JSON-LD] 功能来暗示可验证凭证的内容,但通常不建议使用 @context来约束数据模型的数据类型。例如,“@type”:“@json”对于保持语义开放且未严格定义很有用。如果实现者希望约束凭证中声明的数据类型,这可能会很危险,不建议这样做。

当 credentialSchema 和 @context 属性组合使用时,生产者和消费者都可以对可验证凭证可验证展示的预期内容和数据类型更有信心。

C. 主体与持有者关系

本章节不包含规范性内容。

本节阐述主体与持有者之间可能存在的关系,以及可验证凭证数据模型如何表达这些关系。下图展示了这些关系,后续章节将分别阐述数据模型如何处理每种关系。

Long decision tree
          from top to bottom.  For the first question, 'Subject
          Present?', No means Bearer Credential and Yes points to the
          rest of the tree.  From this point on until the very end,
          each Yes points to an answer and each No points to another
          question.  The first question here is 'Subject = Holder?',
          with Yes meaning Most Common Use Case.  If No, 'Credential
          Uniquely Identifies Subject?' with Yes meaning Irrelevant who
          Holder is.  If No, 'Subject Passes VC to Holder?' with Yes
          meaning, e.g., Power of Attorney, Employee.  If No, 'Issuer
          Independently Authorizes Holder?' with Yes meaning, e.g., Law
          Enforcement.  If No, 'Holder Acts for Subject?' with Yes
          meaning, e.g., Parent, Pet Owner, Travel Agent.  If No,
          'Holder Acts for Verifier?' with Yes meaning, e.g., Recruiter
          passing on VC of job applicant to employer and No meaning
          'Random Holder with no relationship to Subject, Issuer or Verifier
13 可验证凭证中的主体-持有者关系

C.1 主体为持有人

本章节不包含规范性内容。

最常见的关系是主体同时也是持有者。在这种情况下,如果可验证展示(由持有者完成数字签名,且其中包含的所有可验证凭证所涉及的主体都可被识别为与该持有者为同一实体,那么验证者就能轻松推断出主体即持有者。

如果仅允许credentialSubject将可验证凭证纳入可验证呈现,那么颁发者可以在该可验证凭证中加入nonTransferable属性,具体如下文所述。

C.1.1 nonTransferable属性

本章节不包含规范性内容。

nonTransferable属性表明,可验证凭证只能封装到由credentialsubject签发证明的可验证展示中。如果一个可验证展示包含一个带有nonTransferable属性的可验证凭证,但其证明创建者并非credentialsubject,则该可验证展示无效。

C.2 凭证唯一标识主体(非规范性内容)

本章节不包含规范性内容。

在本例中,credentialSubject属性可能包含多个属性,每个属性都提供了主体描述的一个方面,这些属性组合在一起可以明确地标识主体。某些用例可能根本不需要标识持有者,例如检查医生(主体)是否获得了委员会认证。其他用例可能要求验证者使用带外知识来确定主体和持有者之间的关系。

上述例子仅凭借姓名、地址和出生日期便唯一确定了该主体的身份。

C.3 主体将可验证凭证传递给持有者

本章节不包含规范性内容。

通常情况下,可验证凭证由主体呈现给验证者。然而,在某些情况下,主体可能需要将可验证凭证的全部或部分传递给另一个持有者。例如,如果患者(主体)病情严重,无法将处方(可验证凭证)带到药剂师(验证者)那里,朋友可以代为取药。

数据模型允许主体签发新的可验证凭证并将其交给新的持有者,然后新的持有者可以将两个可验证凭证都呈现给验证者。但是,第二个可验证凭证的内容可能特定于应用程序,因此本规范无法标准化第二个可验证凭证的内容。尽管如此,附录 C.5 主体将可验证凭证传递给他人 中提供了一个非规范性示例。

C.4 持有者代表主体行事

本章节不包含规范性内容。

可验证凭证数据模型至少通过以下方式支持持有者代表主体行事:

上述机制描述了持有者与主体之间的关系,并帮助验证者确定该关系是否足以表达给定的用例。

签发者或验证者用来验证主体与持有者之间关系的额外机制不在本规范的范围内。

在上述例子中,签发者阐明了孩子与父母之间的关系,使得验证者更有可能接受由孩子或父母提供的凭证。

在上述例子中,签发者在一个单独的凭证中表达了孩子和父母之间的关系,这样一来,无论这个单独的凭证是否与孩子的任意凭证一起出示,验证者都很可能会接受孩子的任意凭证。

在上述例子中,孩子在一个单独的凭证中表达了孩子与父母之间的关系,这样一来,如果提供了上述凭证,验证者很可能会接受孩子出示的任何凭证。

同样,上述例子中描述的策略可以用于许多其他类型的用例,包括授权委托、宠物所有权和病人处方取药等。

C.5 主体将可验证凭证传递给他人

本章节不包含规范性内容。

当主体将可验证凭证传递给另一个持有者时,主体可以向该持有者签发一个新的可验证凭证,其中:

持有者现在可以创建一个包含这两个可验证凭证的可验证展示,以便验证者可以验证主体是否将原始可验证凭证给予了该持有者。

C.6 签发者授权持有者

本章节不包含规范性内容。

当签发者希望授权持有者持有描述一个非持有者本人的凭证,且持有者与凭证主体之间不存在已知关系时,签发者可以将持有者与自身的关系写入凭证主体的凭证中。

可验证凭证并非授权框架,因此授权不在本规范的讨论范围内。然而,可以理解的是,可验证凭证很可能被用于构建授权和委托系统。以下是一种可能适用于某些用例的方法。

C.7 持有者代表验证者行事,或与主体、签发者或验证者无关联

本章节不包含规范性内容。

可验证凭证数据模型目前不支持上述任一场景。如何支持这些场景有待进一步研究。

D. IANA 注意事项

本章节不包含规范性内容。

本节将提交给互联网工程指导小组(IESG)审查、批准,并向IANA的“JSON Web Token声明注册表”进行注册。

E. 修订历史

本节包含自v1.0版本规范发布为 W3C 推荐标准以来所做的主要变更。

自推荐标准发布以来的变更:

F. 致谢

本章节不包含规范性内容。

工作组感谢以下个人,不仅感谢他们对本文档内容的贡献,还感谢他们在标准社区中的辛勤工作,这些工作推动了众多不同意见之间的变革、讨论和共识:Matt Stone、Gregg Kellogg、Ted Thibodeau Jr、Oliver Terbu、Joe Andrieu、David I. Lehn、Matthew Collier 和 Adrian Gropper。

本规范的工作得到了由Christopher Allen、Shannon Appelcline、Kiara Robles、Brian Weller、Betty Dhamers、Kaliya Young、Manu Sporny、Drummond Reed、Joe Andrieu、Heather Vescent、Kim Hamilton Duffy、Samantha Chase 和 Andrew Hughes 推动的 “重启信任网络” 社区的支持。由 Phil Windley、Kaliya Young、Doc Searls 和 Heidi Nobantu Saul 推动的互联网身份研讨会的参与者也通过旨在教育、辩论和改进本规范的众多工作会议支持了这项工作的完善。

工作组还感谢我们的主席 Dan Burnett、Matt Stone、Brent Zundel 和 Wayne Chang,以及我们的 W3C 员工联系人 Kazuyuki Ashimura 和 Ivan Herman,感谢他们在 W3C 标准化过程中对小组的专业管理和坚定指导。

本规范的部分工作由美国国土安全部科学技术局根据合同HSHQDC-17-C-00019资助。本规范的内容不一定反映美国政府的立场或政策,也不应推断出任何官方认可。

工作组感谢以下个人审查并提供有关规范的反馈(按字母顺序排列):

Christopher Allen、David Ammouial、Joe Andrieu、Bohdan Andriyiv、Ganesh Annan、Kazuyuki Ashimura、Tim Bouma、Pelle Braendgaard、Dan Brickley、Allen Brown、Jeff Burdges、Daniel Burnett、ckenndy422、David Chadwick、Chaoxinhu、Kim (Hamilton) Duffy、Lautaro Dragan、enuoCM、Ken Ebert、Eric Elliott、William Entriken、David Ezell、Nathan George、Reto Gmür、Ryan Grant、glauserr、Adrian Gropper、Joel Gustafson、Amy Guy、Lovesh Harchandani、Daniel Hardman、Dominique Hazael-Massieux、Jonathan Holt、David Hyland-Wood、Iso5786、Renato Iannella、Richard Ishida、Ian Jacobs、Anil John、Tom Jones、Rieks Joosten、Gregg Kellogg、Kevin、Eric Korb、David I. Lehn、Michael Lodder、Dave Longley、Christian Lundkvist、Jim Masloski、Pat McBennett、Adam C. Migus、Liam Missin、Alexander Mühle、Anthony Nadalin、Clare Nelson、Mircea Nistor、Grant Noble、Darrell O'Donnell、Nate Otto、Matt Peterson、Addison Phillips、Eric Prud'hommeaux、Liam Quin、Rajesh Rathnam、Drummond Reed、Yancy Ribbens、Justin Richer、Evstifeev Roman、RorschachRev、Steven Rowat、Pete Rowley、Markus Sabadello、Kristijan Sedlak、Tzviya Seigman、Reza Soltani、Manu Sporny、Orie Steele、Matt Stone、Oliver Terbu、Ted Thibodeau Jr、John Tibbetts、Mike Varley、Richard Varn、Heather Vescent、Christopher Lemmer Webber、Benjamin Young、Kaliya Young、Dmitri Zagidulin 和 Brent Zundel。

G. 参考文献

G.1 规范性引用

[RFC2119]
Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc2119
[RFC7515]
JSON Web Signature (JWS). M. Jones; J. Bradley; N. Sakimura. IETF. May 2015. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc7515
[RFC7519]
JSON Web Token (JWT). M. Jones; J. Bradley; N. Sakimura. IETF. May 2015. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc7519
[RFC8174]
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. B. Leiba. IETF. May 2017. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc8174

G.2 非规范性引用

[CL-SIGNATURES]
A Signature Scheme with Efficient Protocols. Jan Camenisch; Anna Lysyanskaya. IBM Research. Peer Reviewed Paper. URL: https://www.researchgate.net/publication/220922101_A_Signature_Scheme_with_Efficient_Protocols
[DATA-INTEGRITY]
Data Integrity. Manu Sporny; Dave Longley. Credentials Community Group. CG-DRAFT. URL: https://w3c-ccg.github.io/data-integrity-spec/
[DEMOGRAPHICS]
Simple Demographics Often Identify People Uniquely. Latanya Sweeney. Data Privacy Lab. URL: https://dataprivacylab.org/projects/identifiability/paper1.pdf
Cryptographic Hyperlinks. Manu Sporny. Internet Engineering Task Force (IETF). Internet-Draft. URL: https://datatracker.ietf.org/doc/draft-sporny-hashlink/
[IPFS]
InterPlanetary File System (IPFS). Wikipedia. URL: https://en.wikipedia.org/wiki/InterPlanetary_File_System
[JSON-LD]
JSON-LD 1.1: A JSON-based Serialization for Linked Data. Gregg Kellogg; Manu Sporny; Dave Longley; Markus Lanthaler; Pierre-Antoine Champin; Niklas Lindström. W3C JSON-LD 1.1 Working Group. W3C Working Draft. URL: https://www.w3.org/TR/json-ld11/
[JSON-SCHEMA-2018]
JSON Schema: A Media Type for Describing JSON Documents. Austin Wright; Henry Andrews. Internet Engineering Task Force (IETF). Internet-Draft. URL: https://datatracker.ietf.org/doc/draft-handrews-json-schema/
[LDP-REGISTRY]
Linked Data Cryptographic Suite Registry. Manu Sporny; Drummond Reed; Orie Steele. Credentials Community Group. CG-DRAFT. URL: https://w3c-ccg.github.io/ld-cryptosuite-registry/
[LINKED-DATA]
Linked Data Design Issues. Tim Berners-Lee. W3C. 27 July 2006. W3C-Internal Document. URL: https://www.w3.org/DesignIssues/LinkedData.html
[RFC3986]
Uniform Resource Identifier (URI): Generic Syntax. T. Berners-Lee; R. Fielding; L. Masinter. IETF. January 2005. Internet Standard. URL: https://www.rfc-editor.org/rfc/rfc3986
[RFC7049]
Concise Binary Object Representation (CBOR). C. Bormann; P. Hoffman. IETF. October 2013. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc7049
[RFC7516]
JSON Web Encryption (JWE). M. Jones; J. Hildebrand. IETF. May 2015. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc7516
[RFC7797]
JSON Web Signature (JWS) Unencoded Payload Option. M. Jones. IETF. February 2016. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc7797
[RFC8259]
The JavaScript Object Notation (JSON) Data Interchange Format. T. Bray, Ed. IETF. December 2017. Internet Standard. URL: https://www.rfc-editor.org/rfc/rfc8259
[RFC8471]
The Token Binding Protocol Version 1.0. A. Popov, Ed.; M. Nystroem; D. Balfanz; J. Hodges. IETF. October 2018. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc8471
[STRING-META]
Strings on the Web: Language and Direction Metadata. Addison Phillips; Richard Ishida. Internationalization Working Group. W3C Working Draft. URL: https://www.w3.org/TR/string-meta/
[VC-EXTENSION-REGISTRY]
Verifiable Credentials Extension Registry. Manu Sporny. Credentials Community Group. CG-DRAFT. URL: https://w3c-ccg.github.io/vc-extension-registry/
[VC-IMP-GUIDE]
Verifiable Credentials Implementation Guidelines 1.0. Andrei Sambra; Manu Sporny. Credentials Community Group. W3C Editor's Draft. URL: https://w3c.github.io/vc-imp-guide/
[VC-USE-CASES]
Verifiable Credentials Use Cases. Shane McCarron; Joe Andrieu; Matt Stone; Tzviya Siegman; Gregg Kellogg; Ted Thibodeau Jr. W3C. 24 September 2019. W3C Working Group Note. URL: https://www.w3.org/TR/vc-use-cases/
[WCAG21]
Web Content Accessibility Guidelines (WCAG) 2.1. Michael Cooper; Andrew Kirkpatrick; Joshue O'Connor; Alastair Campbell. W3C. 6 May 2025. W3C Recommendation. URL: https://www.w3.org/TR/WCAG21/
[XMLSCHEMA11-2]
W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes. David Peterson; Sandy Gao; Ashok Malhotra; Michael Sperberg-McQueen; Henry Thompson; Paul V. Biron et al. W3C. 5 April 2012. W3C Recommendation. URL: https://www.w3.org/TR/xmlschema11-2/